[eclipse.org-architecture-council] [Bug 273262] New: Request common Bugz

[bugzilla-daemon@xxxxxxxxxxx]

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.