Bugzilla – Full Text Bug Listing
| Summary: | Clarify that EPP packages are not supported products | ||
|---|---|---|---|
| Product: | Community | Reporter: | Martin Oberhuber <mober.at+eclipse> |
| Component: | Cross-Project | Assignee: | Cross-Project issues <cross-project.inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | christian.campo, david_williams, eclipse.org-architecture-council, jacek.pospychala, jeffmcaffer, k.schmidt, mik.kersten, overholt, thomas |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Martin Oberhuber
FYI, the EMO committed to 1) indicating that EPP packages are community support only and 2) providing links to Vendors that offer supported, commercial distros. Beyond this, it's in the community's hands. I just want to add that this issue is, to some degree, broader than the EPP packages. It really applies to any download from Eclipse, right? I'm not sure it deserves any special action, since the EPP packages are the more visible place to put info and information ... just wanted to point that out ... and maybe Architecture council can help get that message across broadly? Another way the "entitlement attitude" manifests itself is the newsgroups. There's no guarantee that questions will be answered, much less answered by committers, and it might help foster "community spirit" if we emphasized the newsgroups were "the community supporting community". (And, naturally, we committers certainly try to be involved, answer questions, etc., ... it's just occasionally I notice a post where someone seems offended (rather than disappointed) that no one answers their question right away. I think CVS is an extreme example (since they are sort of dormant) but some examples of their support statement can be found at http://www.cyclic.com/cvs/report.html, or http://ximbiot.com/cvs/cvshome/cyclic/cvs/report.html Note the phrase in their newsgroups section ("in which users help each other") and their stance about reporting bugs ("Note that someone may or may not want to do anything with your bug report ... People probably do want to hear about bugs which are particularly severe in consequences and/or easy to fix, however.") [I laugh every time I read that "may or may not want to do anything with your bug report" :) I couldn't find it on the web ... maybe it was in their source distribution ... they also say something like "attaching a patch will increase the chances of someone looking at your bug report, but even then ... "] Just some observations about one other open source project. Just a few remarks: First of all Eclipse is free (if you abstract from the money that is paid, e.g. by Strategic Members) but nevertheless it is meant to be the basis of products. The customers buying these products are entitled to quality and product-readiness. If Eclipse cannot deliver these in a reliable way, this will eventually hurt the Eclipse "brand". We are not saying that all submitted bugs have to be fixed, nor do we want to put pressure onto committers. However, if a patch is provided for a bug, we expect that this patch is evaluated and either applied or rejected with a sound reasoning within a reasonable timeframe. For these cases, pointing to commercial distributors (that would then apply our own fix, potentially on a copy of the original code) is not acceptable. If EPP is "community support only", that begs the question, what other support is there? Also, in response to Karstens comment of expectations regarding applying patches; What do you consider being a "reasonable timeframe"? And wouldn't that apply to most bugs? IMHO, the important thing for a bug reporter is that a dialogue commences that ends in some kind of conclusion. Sometimes a patch is involved but far from always. I'm afraid that default expectations on quality and time frames defeats the spirit of Open Source. If a commercial vendor wants more control or guaranteed response times, then they have to ask to join the project or start funding it. To me that's the foundation of the whole Open Source business model. It's based on goodwill and the only expectation you can have is that if you help out, you will also receive help. That's also the message I think the Eclipse foundation should convey. I was talking about the case in which we provided the fix and attached it to the bug. I guess that's what you call "helping out" - at least it's all you can do if you are not a committer (yet). In these cases IMHO closing the bug with a simple "won't fix this one" statement is not an acceptable conclusion. Either a good reason is provided, or the fix is applied. While that sounds reasonable it stops (being that) where you have explain what "a good reason" is. Some people might say "wont fix because I dont think its a good idea" or "wont fix because it doesnt belong here but it belongs some place else". while that is a quit flexible statement you cant force people to accept and apply patches. its still the call of the maintainer (committer) whether he accepts a patch. At the end of the day he also has to continue to support it, fix bugs in the patch and be in general responsible that it is kept in good shape and continues to work. So there is additional work involved beyond the apply patch button. (In reply to comment #5) > I was talking about the case in which we provided the fix and attached it to > the bug. Karsten, which bug is it? It's good your escalating that. I'm not sure though if bug handling is really connected with EPP support policy. (In reply to comment #7) > Karsten, which bug is it? It's good your escalating that. Jacek, I have already discussed the concrete case via e-mail. I do not want to get into public fingerpointing. I firmly believe, however, that this is a general topic. People in different roles have very different views on what Open Source, and especially Eclipse, should mean. Does Open Source mean that bugs in official (correction) releases are acceptable? Is the fact that "there is additional work involved beyond the apply patch button" sufficient to not fix bugs? Shouldn't there be a generally agreed procedure to evaluate the "criticality of the bug vs. risk of the patch" equation instead of leaving that to the good will of the project or the committer? What is the advice to those who are shipping products on top of Eclipse and have to give a warranty to their customers that the product satisfies Product, in particular Quality Standards? It sure can't be to branch off a copy (or pay others to do so) and patch that copy. The conflict is somewhat intrinsic to the Open Source / Eclipse principals. That does not help much but I am afraid that we will not be able to find a solution here. It looks like the discussion here has digressed a little. (In reply to comment #5) > In these cases IMHO closing the bug with a simple "won't fix this one" > statement is not an acceptable conclusion. This touches the somewhat broader topic of "bugzilla netiquette". The Architecture Council is working towards a process for maintaining good bugzilla culture, using bug 256660. Feel free to join the discussion there. We need to collectively work towards a style of interaction that's positive and constructive - because only that way we'll keep our communities active. I'm talking about *style* and *not technical decisions* here. As a matter of style, any contributor deserves a clear explanation why a contribution is not accepted, and may expect this explanation within a reasonable time frame. If any party on the bugzilla discussion (contributor or committer) is mistreated, we need a clear process or escalation. For committers, the escalation process is defined on the "Difficult People" section in http://wiki.eclipse.org/Development_Resources#Committers:_Being_A_Committer For the other party (contributors), we don't have an escalation process yet, and that's part of what we're working on in bug 256660. (In reply to comment #2) > I just want to add that this issue is, to some degree, broader than the EPP > packages. So, to bring the discussion back on topic, the point here is that many people treat some Eclipse Downloads like products. Arguably, we may never be able to stop people from downloading the JEE package and treat it like a product to develop JEE applications. BUT it's the board's desire to (1) clearly highlight that commercial products exist which do offer advantages over the free stuff (2) set expectations right with the free stuff. This bug's goal is to find the right measures / words to do that. It's true that this is theoretically an issue with any Eclipse download - but "integrated" stuff like the packages, the Train artifacts, the Modeling Amalgamation Downloads, or the WTP and PDT "all-in-one" downloads are the primary candidates to be mis-treated as products. I thus believe that the Planning Council / the Train should decide how to set expectations right. If the result is a particular kind of wording or particular kind of setup on the download pages, other projects may later copy this. Is anyone taking any action here? I suggest we close it as wontfix, but didn't want to close it if someone really had something in mind they would do. Thanks, (In reply to comment #10) > Is anyone taking any action here? I suggest we close it as wontfix, but didn't > want to close it if someone really had something in mind they would do. It's been over a year since David said this. Should we perhaps close this? Maybe the long-term support initiative could help here? I tend to agree that with the actions as per comment 1 this can be closed. Is anyone still feeling pain due to this? Any concrete actionable requests for the download page http://eclipse.org/downloads/ ? I like having the member downloads and the "ads" on the side. The link to the SUA is good and IMHO people have taken care of this bug outside of a big flash red "unsupported!" which probably isn't desirable ;) Closing, because apparently Andrew and Martin are just too nice to do it ;) |