|[eclipse.org-architecture-council] [Bug 273262] New: Request common Bugzilla markup to identify patches post SR2|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=273262 Product/Component: Community / Architecture Council Summary: Request common Bugzilla markup to identify patches post SR2 Product: Community Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Architecture Council AssignedTo: eclipse.org-architecture-council@xxxxxxxxxxx ReportedBy: martin.oberhuber@xxxxxxxxxxxxx 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? -- Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
Back to the top