So, I just voted in the Eclipse Board elections. I encourage everyone entitled to a vote to do the same.
I'm not feeling the greatest about the security of the whole thing though. My password to login to the voting system was sent via email, which is not a very secure protocol given that the contents are sent out in the clear. Why couldn't I just login using my SSH credentials, which are relatively secure? Granted, the likelihood that someone is sniffing committers' email in an attempt to fraudulently login and rig the board elections is pretty low, but it's the principle of the thing.
Even worse, was that after I voted, the system told me to expect a confirmation email. Ok, great. Except, the confirmation email contains a listing of how I voted for all the candidates. So much for secret ballots. Oy.
Wednesday, February 27, 2008
Thursday, November 22, 2007
Toronto DemoCamp tonight!
Just a reminder that the Toronto DemoCamp is tonight. Come out to see some cool Eclipse demos, talk to other Eclipse enthusiasts (and committers!), and have some free refreshments.
And yes, the weather is a bit crappy today, but we're still on! The snow is supposed to stop this afternoon.
Hope to see you at DemoCamp!
And yes, the weather is a bit crappy today, but we're still on! The snow is supposed to stop this afternoon.
Hope to see you at DemoCamp!
Thursday, November 15, 2007
One Week Till Toronto Demo Camp
We have some cool demos lined up:
- Marcelo Paternostro, EMF: Building an Ecore model and seeing what EMF can do with it
- Mike Kucera, CDT Using Parser Generators To Build CDT Parsers
- Shaun Smith, Eclipse Persistence Services (EclipseLink) & Dali JPA Tools--Object/XML and Object/Relational mapping in Java
- Eugene Kuleshov, Task management and team collaboration with Eclipse Mylyn (Mylyn)
Thursday, October 18, 2007
Paintball, The "Other" Planet Eclipse, and A Humble Request
The other day a bunch of us here in the lab went out paintballing as a sort of team-building event. Little did the poor saps know that I used to play every single weekend, have all my own gear, etc. Needless to say the other team was frequently punished by the steady rain of purple paint from my tricked out Classic Automag .68 hammering down upon them. Muwahahah.
Oddly enough, going out with my co-workers has bitten me with the paintball bug again, so when waiting on a build I was checking around online to see how much some of the new markers I like cost. While looking around, I saw for sale a "Planet Eclipse 07 Ego" paintball marker. "There's an Eclipse paintball marker? COOL!!!" Intrigued, I Googled further, and it seems that http://www.planeteclipse.com is the website for the paintball company called (you guessed it) Eclipse that makes this particular marker.
They even have a marker that comes in a cool purplish-blue colour that sort of fits with the theme of our favourite IDE...
So instead of giving away Eclipse mountain bikes this year, how about some cool Eclipse paintball swag? This is way cooler than a mountain bike...
Here's hoping anyway :-)
Oddly enough, going out with my co-workers has bitten me with the paintball bug again, so when waiting on a build I was checking around online to see how much some of the new markers I like cost. While looking around, I saw for sale a "Planet Eclipse 07 Ego" paintball marker. "There's an Eclipse paintball marker? COOL!!!" Intrigued, I Googled further, and it seems that http://www.planeteclipse.com is the website for the paintball company called (you guessed it) Eclipse that makes this particular marker.
They even have a marker that comes in a cool purplish-blue colour that sort of fits with the theme of our favourite IDE...
So instead of giving away Eclipse mountain bikes this year, how about some cool Eclipse paintball swag? This is way cooler than a mountain bike...
Here's hoping anyway :-)
Friday, October 5, 2007
BeerClipse Meetings?
I just read Ian's blog about demo camps.
An interesting thought.
In addition to this sort of one-time thing, perhaps we could do something like the 2600 meetings. Set a standard time, like the second Friday of the month or something like that, to be the standard day for meetings. Then, people could locally organize their own meetings at that time at their local foodcourt/pub/whatever.
The 2600 meetings range from organized events with actual agendas and presentations, to informal "let's show up and shoot the breeze about hacking" meetings. The nature of the meeting is up to the organizers.
I think you could do something similar for Eclipse and have it be pretty successful. If nothing else. the promise that committers will be there will definitely draw in the user and contributer community because they'll want to corner us and ask questions. And if they don't show, there would always be stuff that we committer folk could talk about amongst ourselves over some frosty beverages.
What do people think about this idea? Would you participate on a regular basis?
An interesting thought.
In addition to this sort of one-time thing, perhaps we could do something like the 2600 meetings. Set a standard time, like the second Friday of the month or something like that, to be the standard day for meetings. Then, people could locally organize their own meetings at that time at their local foodcourt/pub/whatever.
The 2600 meetings range from organized events with actual agendas and presentations, to informal "let's show up and shoot the breeze about hacking" meetings. The nature of the meeting is up to the organizers.
I think you could do something similar for Eclipse and have it be pretty successful. If nothing else. the promise that committers will be there will definitely draw in the user and contributer community because they'll want to corner us and ask questions. And if they don't show, there would always be stuff that we committer folk could talk about amongst ourselves over some frosty beverages.
What do people think about this idea? Would you participate on a regular basis?
Tuesday, September 25, 2007
Java Makes It Hard to Find Good Help These Days...
From the Google-alerts-are-cool department:
Leif Frenzel has posted an interesting blog entry on the difficulties of creating tools for non-Java languages in Eclipse. He argues that in order to have tools that rival JDT, you have to have complicated tools that have intimate knowledge of the syntactic structure and semantics of the user's code, and this is hampered by the inability to code plug-ins easily in anything but Java. It's hard to find for example a parser generator that can handle Haskell, unless you're willing to use a parser generator written in Haskell itself. Go read it. Interesting food for thought.
Leif argues that this makes it hard for the community to contribute, because inherently the people that are most interested in seeing support for the language in question are people that are heavy users of that language, which also means that it's likely that their primary language of choice is not Java.
This makes sense to me because I've seen it first hand when trying to hire new members of my team that works on CDT. It's difficult to find people that have both good Java skills (needed for writing plug-ins), and a good knowledge of C and C++ (needed to know what the heck our plug-ins should be doing).
Would we find it easier to get help on CDT (both in terms of new hires, and in terms of help from the community) if people could write plug-ins in C++? Hmm... maybe...
Food for thought anyway. Personally I prefer writing my plug-ins in Java, thanks.
Leif Frenzel has posted an interesting blog entry on the difficulties of creating tools for non-Java languages in Eclipse. He argues that in order to have tools that rival JDT, you have to have complicated tools that have intimate knowledge of the syntactic structure and semantics of the user's code, and this is hampered by the inability to code plug-ins easily in anything but Java. It's hard to find for example a parser generator that can handle Haskell, unless you're willing to use a parser generator written in Haskell itself. Go read it. Interesting food for thought.
Leif argues that this makes it hard for the community to contribute, because inherently the people that are most interested in seeing support for the language in question are people that are heavy users of that language, which also means that it's likely that their primary language of choice is not Java.
This makes sense to me because I've seen it first hand when trying to hire new members of my team that works on CDT. It's difficult to find people that have both good Java skills (needed for writing plug-ins), and a good knowledge of C and C++ (needed to know what the heck our plug-ins should be doing).
Would we find it easier to get help on CDT (both in terms of new hires, and in terms of help from the community) if people could write plug-ins in C++? Hmm... maybe...
Food for thought anyway. Personally I prefer writing my plug-ins in Java, thanks.
Monday, September 10, 2007
Blog to Blog: Diversity
I was going to post a comment to Bjorn's blog entry about diversity, but I thought my response was food for thought enough (and controversial enough!) to merit its own blog entry. These thoughts have been simmering for a while.
I think diversity is good. A lot of projects need more diversity. However, I think that until the Platform has a non-IBM committer that is doing more than just contributing builds of SWT for a non-primary platform, then diversity at Eclipse is somewhat of a farce. The Platform, if anyone, should be a shining paragon of diversity and openness to the rest of the projects on Eclipse.org, but it's the number one project that people complain about with respect to diversity and openness.
It is very hard to get contributions in to the platform (often with good reason, we don't want crap in there obviously...), and as a result, it is hard to build up enough of a reputation to become a platform committer. While the platform team are good at posting plans and information, the processes that go into them are essentially closed. The day to day discussions about design and development issues do not seem to happen in an open forum. There are no public conference calls, and the mailing lists don't have significant traffic about the actual development going on in the platform. Instead they usually amount to status reports on builds and testing, peppered with the odd user question (which usually ought to have been posted to the newsgroups instead). And no folks, Bugzilla on its own does not count... not everyone has time to keep hitting refresh on Bugzilla to see what bugs are appearing and how they are going to be fixed. People at least need a heads up that "Hey, we're discussing $BIG_ISSUE over on Bugzilla #whatever, go there if you're interested in the discussion." Also, I would say that Bugzilla is not the greatest forum for discussing broader issues and project plans, etc.
In this sort of environment, it's hard to build a sense of camaraderie with the team. There is a definite "US and THEM" atmosphere. Not that the Platform people are adversarial, don't get me wrong. But, you definitely don't get the feeling they are actively trying to get newcomers into the fold. It's difficult to get enough information about what's going on in order to try to get up to speed to the point where you're on somewhat of an equal footing.
Now to be clear. I'm not trying to slag the Platform or the people that work on it. They have done a ton of awesome work over the years and we all owe a lot to them. Theirs is no easy job at the best of times. But, I do think there are things that they and other projects could be doing better, and so I'm trying to criticize constructively. Hopefully everyone takes it as such.
Now, let's contrast the status quo with the Platform project with my experience with becoming a committer on CDT. The company I was working for at the time was looking to move their IDE to the Eclipse/CDT platform. As I started coding up our integration, I started hanging on out the cdt-dev mailing list, reading and eventually participating in the in-depth requirements gathering and technical discussions that went on there. CDT conference calls were (and still are) open to the public, so I just started showing up. At first I didn't have a lot of useful things to say other than introducing myself and communicating that our company was starting to use CDT and was looking to contribute, but over time as I got ramped up, I had more meaningful things to say.
After fixing a few bugs on the 2.0 release, CDT 3.0 came along, and there were some features that I needed implemented that the commiters (of which I wasn't one yet) indicated that they didn't have time to work on. So what did I do? Well I hopped on the planning conference call and told them that I was committing to deliver patches for those features for the release. "Great!" they said, and put my items on the plan with my name next to them. I did what I promised and after the release went out I was rewarded with a nomination and subsequent election to commit rights.
The difference was the CDT gang went out of my way to make me feel like I was part of the team, even if strictly speaking I didn't have commit rights yet. Discussions and information were open enough that I could participate as nearly a first class citizen. Sure, I still had to submit patches for anything I wanted to change, and convince someone that those patches were worth committing, but that's much easier to do when you've already been collaborating as near-equals for a while. The open and collaborative nature of the project allowed me to build up an important thing: trust.
Anyway, back to the point.
I think really that the focus of the diversity rules and enforcement should not be to stop projects from starting that are not yet diverse, but instead should focus on opening up projects that already exist but are not diverse. I don't think diversity rules should get in the way of contributions. It's better to have a non-diverse project than no project at all, because it's better to have imperfect code that does something for someone, rather than have no code, which does nothing for everyone.
That being said, if a project exists and people can't contribute even when they want to, then that is a definite problem which we should be trying to fix.
Admittedly the devil is in the details, especially with a project as large and as widely consumed as the Platform, but without trying to sound heavy-handed, I think we should be looking at ways to open up it and other projects. Such changes would have to be practical. Maybe, for instance, you can't have a 100% open Platform Conference Call where anyone and everyone that dials in can say whatever they want, because you could get far too much signal to noise. But, maybe you can have a moderated call, where some people who are known and trusted (e.g. Eclipse committers) can speak freely, and others can flag questions for the moderators attention. This way information still flows, but hopefully supporting that flow is not onerous for the committers.
At any rate, I'm curious to see what's going to happen with this new diversity push. The Platform Debug team has been setting a good example as of late, and is actively trying to mentor in some new committers on the Debug sub-project. Kudos to them, and hopefully we will start seeing more things like this.
I think diversity is good. A lot of projects need more diversity. However, I think that until the Platform has a non-IBM committer that is doing more than just contributing builds of SWT for a non-primary platform, then diversity at Eclipse is somewhat of a farce. The Platform, if anyone, should be a shining paragon of diversity and openness to the rest of the projects on Eclipse.org, but it's the number one project that people complain about with respect to diversity and openness.
It is very hard to get contributions in to the platform (often with good reason, we don't want crap in there obviously...), and as a result, it is hard to build up enough of a reputation to become a platform committer. While the platform team are good at posting plans and information, the processes that go into them are essentially closed. The day to day discussions about design and development issues do not seem to happen in an open forum. There are no public conference calls, and the mailing lists don't have significant traffic about the actual development going on in the platform. Instead they usually amount to status reports on builds and testing, peppered with the odd user question (which usually ought to have been posted to the newsgroups instead). And no folks, Bugzilla on its own does not count... not everyone has time to keep hitting refresh on Bugzilla to see what bugs are appearing and how they are going to be fixed. People at least need a heads up that "Hey, we're discussing $BIG_ISSUE over on Bugzilla #whatever, go there if you're interested in the discussion." Also, I would say that Bugzilla is not the greatest forum for discussing broader issues and project plans, etc.
In this sort of environment, it's hard to build a sense of camaraderie with the team. There is a definite "US and THEM" atmosphere. Not that the Platform people are adversarial, don't get me wrong. But, you definitely don't get the feeling they are actively trying to get newcomers into the fold. It's difficult to get enough information about what's going on in order to try to get up to speed to the point where you're on somewhat of an equal footing.
Now to be clear. I'm not trying to slag the Platform or the people that work on it. They have done a ton of awesome work over the years and we all owe a lot to them. Theirs is no easy job at the best of times. But, I do think there are things that they and other projects could be doing better, and so I'm trying to criticize constructively. Hopefully everyone takes it as such.
Now, let's contrast the status quo with the Platform project with my experience with becoming a committer on CDT. The company I was working for at the time was looking to move their IDE to the Eclipse/CDT platform. As I started coding up our integration, I started hanging on out the cdt-dev mailing list, reading and eventually participating in the in-depth requirements gathering and technical discussions that went on there. CDT conference calls were (and still are) open to the public, so I just started showing up. At first I didn't have a lot of useful things to say other than introducing myself and communicating that our company was starting to use CDT and was looking to contribute, but over time as I got ramped up, I had more meaningful things to say.
After fixing a few bugs on the 2.0 release, CDT 3.0 came along, and there were some features that I needed implemented that the commiters (of which I wasn't one yet) indicated that they didn't have time to work on. So what did I do? Well I hopped on the planning conference call and told them that I was committing to deliver patches for those features for the release. "Great!" they said, and put my items on the plan with my name next to them. I did what I promised and after the release went out I was rewarded with a nomination and subsequent election to commit rights.
The difference was the CDT gang went out of my way to make me feel like I was part of the team, even if strictly speaking I didn't have commit rights yet. Discussions and information were open enough that I could participate as nearly a first class citizen. Sure, I still had to submit patches for anything I wanted to change, and convince someone that those patches were worth committing, but that's much easier to do when you've already been collaborating as near-equals for a while. The open and collaborative nature of the project allowed me to build up an important thing: trust.
Anyway, back to the point.
I think really that the focus of the diversity rules and enforcement should not be to stop projects from starting that are not yet diverse, but instead should focus on opening up projects that already exist but are not diverse. I don't think diversity rules should get in the way of contributions. It's better to have a non-diverse project than no project at all, because it's better to have imperfect code that does something for someone, rather than have no code, which does nothing for everyone.
That being said, if a project exists and people can't contribute even when they want to, then that is a definite problem which we should be trying to fix.
Admittedly the devil is in the details, especially with a project as large and as widely consumed as the Platform, but without trying to sound heavy-handed, I think we should be looking at ways to open up it and other projects. Such changes would have to be practical. Maybe, for instance, you can't have a 100% open Platform Conference Call where anyone and everyone that dials in can say whatever they want, because you could get far too much signal to noise. But, maybe you can have a moderated call, where some people who are known and trusted (e.g. Eclipse committers) can speak freely, and others can flag questions for the moderators attention. This way information still flows, but hopefully supporting that flow is not onerous for the committers.
At any rate, I'm curious to see what's going to happen with this new diversity push. The Platform Debug team has been setting a good example as of late, and is actively trying to mentor in some new committers on the Debug sub-project. Kudos to them, and hopefully we will start seeing more things like this.
Subscribe to:
Posts (Atom)
