I think that in general, the response to submitted bugs is exceptionally good at Eclipse.org. At least compared to most other open source communities where I’ve been involved. There are exceptions to the rule of course, and I agree that bugs that even has patches attached to them most certainly deserves a response. Not so sure it’s a good idea to try and enforce it though.

It would be easy to ensure timely responses if the bug-submitters were willing to pay a support contract but chances are high that the added bureaucracy that comes with that just makes things worse. Compare the support you get from Eclipse.org with what you get from a commercial vendor like IBM, Oracle, Microsoft, etc. I don’t think anyone would like us to switch to a model more similar to theirs.

It seems to me most of the bugzillas you cite have been reasonably handled. I get this feeling of “complaints about the salad”…

As for strict policies, keep in mind that those who provide free things are under absolutely no obligation to meet the arbitrary demands of others. Once money changes hands, then you’ll be in a position to specify policies and enforce them.

It’s great when contributors take the time and effort to provide patches, but it takes a significant amount of committer time to review the work. The majority of patches I see are one off contributions by individuals who do not have, and are not trying to, gain a full understanding of the component. Instead the patches simply solve the one problem they are having, with no consideration for how the change affects the rest of the component. Bugs with patches should (and I would argue, do) get more attention. However, it is unreasonable to demand that committers, who have to make their employer’s interests a priority, spend the time to review every patch provided by the community.

I appreciate the difficulty of accepting patches while simultaneously maintaining a project and developing new features or taking it in a new direction. Not an easy task. Project leaders have to triage. They’re busy, brilliant people whom I hold in the highest regard.

However as one who builds with Eclipse, waiting 1.5 years for a feature or bugfix is completely unacceptable. This is why I think DVCS like git have the potential to absolutely transform the Eclipse ecosystem. Our patches won’t just sit scattered in Bugzilla tickets gathering dust if we can cherry-pick them into our products.

I’m not advocating total anarchy. We desperately need project owners to make the final decision for what is most appropriate, pick the best of the best, keep coding standards, API compatibility, IP compliance, etc. But I think we also need some seething DVCS chaos to eliminate some of the bottleneck.

This chaos involves risk. Some of us (or our employers) will be very conservative, and only work from those major baseline releases. They are the ones who should be heavily funding those baselines. Others of us are lean & mean startups, comfortable with tearing through the sources, willing to sacrifice some API changes in the next major release to get a feature out today… We may not have deep pockets, but we can bring a marketplace of ideas, if there’s somewhere to share them.

My personal experience with providing bugs and patches is completely positive. I’m always surprised how fast the Eclipse Committers react and about the quality of the feedback.

I agree with Eugene on this point. Being a long follower of Eclipse and developer of the commercial products based on Eclipse, just only makes me a “friend” (or whatever it means when you donate the money) of Eclipse and far away from the feeling myself a contributor or being interested feeling like one, even though I filed a bugs (with patches).

I see the patch I have submitted few months ago lying dead (bug is tiny and obvious in PDE) without any response or QA assignment and that is exactly what makes me less interesting to submit something similar next time.

I also understand that the voices in open community are heard based on meritocracy principle. But what it is has to do with QA? If the Foundation is a “trade association” or whatever commercial entity it may call itself, it makes really lousy work with QA of it’s main product.

I would love to see higher standards on bug tracking and resolutions. This would help not only the product, but also myself feeling more likely to contribute next time. Hope I’ll be heard.

I agree that bugs with patches don’t get enough attention, but unfortunately there just aren’t enough committers to handle them all. There are >1000 open bugs with patches in the Eclipse top-level project (http://tinyurl.com/eclipseopenwithpatch), and only a small number of active committers able to commit them. However, very many patches *do* get a applied, so it’s hard to draw any interesting conclusion from a small sample. You can easily browse the Eclipse project IP log to see a list of contributed patches that were actually applied in 3.5:

http://www.eclipse.org/eclipse/development/project-log-files/eclipse_project_3_5_log.html

I think Eugene has a valid point. In my experience most projects are good in processing patches, but a few are bad.

The problem from my POV is that for outsiders it is impossible to tell before hand what to expect from a project and what communication channels exist to move bug resolution forward:

- What is the average time to resolve a bug?
- How much re-work / additional work is expected?
- How long should I wait before “nagging”?
- This issue is stuck. Who can I PAY to resolve bugs or process patches right now ?

Some quick ideas:

- Projects should publish information about how to resolve bugs, contract support, average bug resolution times
- From my POV it’s better to say this needs work, would you like to contract me or somebody to do this, instead of just ignoring the issue.
- A bugzilla field for attaching a “bounty” to bugs – as in I would like to pay X dollars to have this fixed.
- A directory of committers than can be contracted to fix bugs quickly. It is not apparent to outsiders who is available for this type of work.

This is completely the wrong attitude to take in my opinion. I think in the majority of the cases, patches have been accepted and applied. Have all? No, but this is a fact of any environment that has a set of limited resources.

If certain open source components are critical to your business, how about considering investing some resources and stating your interest in participating in the project? The quickest path to ensure your work gets into the projects you care about is to become a committer.

For patches that linger, feel free to bug the committers more. Nagging surprisingly works in most cases.

In the end, just like in life, it’s all about relationships. If committers trust you and there’s a relationship there, your patches will get in faster. On certain core projects, committers have to be very careful to preserve API and behavior… which many contributors may not care about.

In regards to the DVCS note, it will definitely make it easier for people to maintain their own forks and contribute their fixes back. Part of the problem of currently maintaining your fork is the maintenance of patches and keeping up with Eclipse as it evolves. Git makes this much easier than it currently is with CVS and SVN. This is why I’m pushing big to enable Git at Eclipse. On top of that, we may want to consider having something where companies can “publicly” fork certain Eclipse projects so people are aware of it.

On a side note Eugene, if the Symbian Foundation would like to be more involved at Eclipse, there are ways to make that happen

[...] bills. I nodded like everyone else. And we talked about Eugene Ostroukhov and his complaint ““Participate in community!” they said…“. And I immediately saw a parallel in my own history. I had a similar, painful experience [...]

[...] the time to work on 3.x (when reading blogs like this from Eugene Ostroukhov my willingness to invest spare time on it is equal to 0) TOTAL [...]