Bjorn and Doug both talked about how Eclipse is us! Us, not as committers, not as paid employees, not even us as bloggers on planeteclipse.org, but as members of the Eclipse Community. Bjorn, Doug, I agree!
However, I think this line of thought works a little bit better in theory than it does in practice. Without drawing attention to any one component or bug report, I doubt *just anyone* could start using Eclipse and fix bug #X or completely understand the design behind feature #Y. This is not because we are incapable or lazy, but rather we cannot do it the Eclipse Way, the way the *owner* of the component wants it done. That is akin to saying anyone can just change the linux kernel and Linus would be happy to apply the patch. While patches come from contributors, committers are the ones who have to maintain them. I have seen features come to Eclipse as part of a patch, only to have them rejected because they were not something that has perceived value for enough of the community. And this is a judgment call that a single committer can make.
And this only scratches the surface when it comes to frustration. There are bug reports that have been open for years. Some with little or no feedback. Some with patches than can be applied (or at least they could have when the patch was submitted), still waiting in the queue. In this case, someone took the time to report the problem, they spent their energy fixing it instead of complaining about it, and in the end, nothing changed.
I don't want people to get the wrong impression here. I have missed bug reports, I have forgotten to commit patches and I have decided not to fix a bug because it doesn't fit in the overall design of a component. Nobody's perfect and sometimes we need a little reminder, but for some of the more mature projects at eclipse.org, you have to be well respected even to get a response.
1 comment:
Let's also not forget that even when a bug is fixed to the reporter's satisfaction (through contribution of a patch, for example), it often doesn't get put through for political reasons; whether that's the politics of 'if it ain't broke, don't fix it' or through the desire not to change things.
As an example, the EFS provider throws a 'filesystem not writable' exception when trying to invoke the putInfo() call. However, that's not accurate; the file system can be writable; it's that the developer hasn't overriden this method. There's a bug request just to change this documentation; and it's been closed WONTFIX in case anyone is depending on that specific string returned (despite the fact that it's a localised string anyway).
In addition, some fixes require access to Eclipse foundation hardware (for configuration purposes). I raised an enhancement to create a URL http://downloads.eclipse.org as an alias to the existing http://download.eclipse.org; not only is the plural form more correct (c.f. http://bugs.eclipse.org instead of http://bug.eclipse.org). That would take less than an hour of my time to configure an existing BIND/Apache implementation; but it was RESOLVED CANTBEARSED in the report.
Another example is that of the URLs generated by the download pages for the SDK that require you to click through several pages before getting to what you want; that's why I posted the direct download links at http://www.eclipsezone.com/eclipse/forums/t86437.html for people to be able to get single-click, right-click to save-as, and it uses the existing Eclipse.org infrastructure to do redirects to mirrors. I'd have certainly been able to knock this one out in less than the 6 months that it's currently taken for anyone to do anything about this.
Lastly, there are some bugs that enhance the UI but the status-quo is easier to maintain. For example, the 'Run->Run...' is a really bad UI design; and the fact that you have to distinguish between internal/external tools and run/debug is silly. They should all be condensed into one Launch Configurations dialog (albeit probably accessed from separate Run and Debug buttons). There's no reason this dialog can't have both a 'Run' and 'Debug' button (instead of the single Run/Debug depending on how you opened it) and allow you to manage your Ant builds in exactly the same place as the Java launches.
None of these bugs have been solved, because it has been decided that these 'do not fit' with the way that the Eclipse teams wants to do things.
I even developed a plugin that allowed Kerberised CVS access a year ago; that's still waiting as a bug with the code attached.
Realistically, if the Eclipse team behind the scenes doesn't need to use something, it doesn't get integrated in. The CVS+Kerberos access is ready to roll; the fact that Eclipse committers don't use CVS+Kerberos means that it's not been added. Similarly, the JDT team has invented all sorts of Clean Up wizards to automatically delete code from your code base, but because they don't Sort Members, the option to have Sort Members in a Clean Up operation doesn't exist (and that's despite the same bug saying 'do organise imports/code format/sort members on save'. Guess which ones they implemented; and then marked the bug as closed?)
Oh, and don't get me started about all those RESOLVED NEVER/LATER/REMIND/CANTBEARSED bugs. If the bug tracking system were open to 'the community', then 'the community' would have done something about it by now. It's not; it's tightly controlled by the various Eclipse committer teams.
So no, Eclipse is not 'me'. Eclipse is definitely the commiter teams behind the scenes; they control what goes into Eclipse, and it's usually what they want, not what the community wants.
Alex.
Post a Comment