Community
Participate
Working Groups
Many Eclipse Projects (most prominently the Eclipse Platform project) do not produce maintenance builds post SR2 (like 3.3.2 or 3.4.2). But still, there are commercial adopters of Eclipse who need to guarantee support for their products over a much longer period, sometimes as long as 10 years. Therefore, there is a need for bug fixes post SR2. I'd like to see improvements in how the Community organizes around such fixes to older Streams. I see three aspects of this: 1. Information -- letting others know what fixes were made 2. Builds -- making sure that everybody can build Eclipse 3. Officially organizing / accumulating patches to avoid late conflicts of patches for end-users. This bug deals with the first item only. I'd like to see some common means of markup on bugzilla to ensure that anybody can run queries to find post-SR2 patches that have been rolled out in some product to end-users. Note that the EPL requires anybody who makes such patches to make the patches public; therefore, Bugzilla seems a good means for documenting these patches. Here are some possible suggestions: (a) Target Milestone = "3.4.2+" (b) Version="3.4.2" AND has patch AND has review+ (c) Resolution="FIXED" AND Target Milestone = "---" AND has patch (d) Has comment regex="Released by .* after 3.4.2" One problem of option (d - using a comment) is that once a comment is there, it cannot be undone. From all other options, I personally like (a) best since it is self-documenting and easy to understand. Note again that we are *not* shooting for public releases of 3.4.3 or similar -- in fact a "3.4.2+ release" will never happen. We are also *not* shooting for allowing anybody to tag their unreviewed patches. The guiding principle of markup should be that only patches receive the markup which have been released by some company into some commercial product (and therefore, of course, received adequate review and testing). Thoughts, comments, ideas?
I have the feeling that including a version or target milestone is too limiting. There are many possibilities here. For example, patches get approved and committed to HEAD only. This might be caught by option (b). However, it does not cover a patch sitting around against 3.3 which did not get committed for some reasons. Having a "patch" keyword (or a tag) feels right to me. But then again, there might be stuff which qualifies as an important fix to a maintenance stream but was never done because of lack of interest. How do we want to capture those? Not all might contain actual patches but only references to commits.
This is great idea. afaik JDT maintains something like that on their http://www.eclipse.org/jdt/core/dev.php page - see Bug resolution links for releases. Having just information about eventual fixes with no ability to get builds from Eclipse.org might be not enough motivation for companies to drop back any info to bugzilla. The same for committers - would they really review patches that are not going to be applied or used in build? Are you proposing: - just keep information in bugzilla that XYZ has provided patch for bug 123 for release 2.0? - keep information in bugzilla AND apply patch to R_2_0_maintenance, but not invoke build
I'm sorry but there is something unsettling for me about the naming "3.4.2+". I can't quite put it into words, but I would be more comfortable with a keyword system to find these patches. It's just a feeling.
+1 for doing something here. We currently just release these fixes into the maintenance branch (such as R3_4_maintenance, R3_3_maintenance, etc), but have no consistent way to identify the corresponding bug reports. If for nothing else but our own sanity I think this would be helpful. I would limit this markup to bugs that have been committed to a maintenance branch, rather than just any bug with an uncommitted patch. This way anyone in the community could do their own local build on that branch if they desired, and know what bugs were addressed in it (ability to run complete local builds may vary by project, but anyone could checkout the branch and do their own build on a single plugin). The target milestone field does seem like the natural place to record this, although this would be inconsistent across projects because everyone has different release numbers. Another option would be putting the branch name in the status whiteboard (I did this as a test in bug 271457).
The "Status Whiteboard" is an interesting idea. What is this usually used for, and are there any constraints like with keywords (which must be from a known set of words)? One motivation for this bug actually was that (at least today) not everybody is able to commit changes to the maintenance branch; yet there is a need for those fixes, and some companies actually make fixes or otherwise patch Eclipse today (because they don't get their requested fixes committed). My initial motivation for this bug was to collect information about "what's out there in the wild": that is, what changes have been released into products. This information is relevant for several reasons: 1. A fix which company A found important enough to release into a product may likely be interesting for company B too. There is potential for synergy. 2. End user X may want to use a product from company A with plugins from company B. If both A and B include post-SR2 fixes, there is potential for conflict, especially given the fact that fixes can only be made on a per-plugin granularity - consider both A and B fixing org.eclipse.ui but differently, only one of them can win. Knowing this is the first step to resolution. I acknowledge that some changes released by a company into the market may patch Eclipse in ways that are not agreed on by everybody (and therefore wouldn't ever be committed into CVS). Still, the information that it's out in the wild is very relevant. In most cases, though, the fact that a company considers a patch important enough to release into the market is a good indicator that this may be a candidate for committing to CVS eventually. Perhaps we'll actually need two kinds of markup: (a) committed to maintenance branch, and (b) released into a product but not committed to the maintenace branch. In the case of (b) there can actually be multiple companies picking up the change in their products even if the change is not going into CVS. The important point to consider, though, is that there must be a clear requirement for quality and importance of the fixes to be marked. If anybody marks just any fix as "post SR2 patch" that they like, the information is way less useful than if only tested, released changes are marked. So, what about this proposal: 1. We don't use target milestone since we're not doing any formal release. 2. We use a keyword ("committed") for changes that were committed into a maintenance stream after the last scheduled release. In addition to the keyword, the status_whiteboard could indicate 2.1. The branch name, or better yet the release train name ("galileo") 2.2. A list of affected bundles If a single fix is commmitted into multiple maintenance streams, multiple bugs ("clones") are used. 3. We use another keyword ("public") for changes that were released by a company into a product that's publicly available. In addition to that, we can use bugzilla flags e.g. WindRiver: public+, SAP: public+ etc. Along with a "public" flag, a comment should indicate product name and release into which the change was released. I think that using these concepts, there is potential for some interesting queries. Just using keywords (and train names) means it works across project boundaries, though restriction of scope is possible by bugzilla fields such as "Product" and "Version": * Query e.g. all public but not committed * Query all committed * Query all "public" changes to org.eclipse.ui * Query all "public" changes in product Foo from company Bar
The Eclipse Project PMC recently decided to use the bugzilla target milestone for identifying patches post SR2 -- for instance, we now have "3.5.2+" What do people think, should we document / propose this as a standard for other projects as well, or just mark this bug closed?
(In reply to comment #6) > The Eclipse Project PMC recently decided to use the bugzilla target milestone > for identifying patches post SR2 -- for instance, we now have "3.5.2+" > > What do people think, should we document / propose this as a standard for other > projects as well, or just mark this bug closed? Ah, I knew we had discussed this before but had lost track of this bug report. We made the decision to use "3.5.2+" without really considering alternatives such as the status whiteboard. In any case I think the most important thing is having some consistent way of marking such bugs, and documenting it. We have done this for the Eclipse top-level project with documentation here: http://wiki.eclipse.org/Eclipse/Bug_Tracking#Target_Milestones I suspect this approach won't work for other projects that do have additional releases after SR2 has completed, but may be suitable for projects that have officially ended development in a given stream but still occasionally release patches into CVS.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
We won't be investing any resources into improving Bugzilla, as we encourage projects to use GitHub and Eclipse GitLab (https://gitlab.eclipse.org). Please see: Shutdown this bugzilla instance. https://bugs.eclipse.org/bugs/show_bug.cgi?id=577151
