RE: [wtp-pmc] Marking bugs for official patch

["Raev, Kaloyan" <kaloyan.raev@xxxxxxx>]

OK. It seems that option 1 is more preferable. Therefore, I suggest that we create a new target milestone in Bugzilla, called "3.0 P", where all patch candidate bugs should be targeted. Similarly, Dali and JSF projects should have a new "2.0 P" target milestone. The "P" target milestone should be perceived as an intermediate milestone between the official release and the next maintenance release. That is "3.0 P" is after "3.0", but before "3.0.1". In this order of thoughts any bug fixed at "3.0 P" should be fixed in "3.0.1" as well.

 

I am not sure on how do we use the whiteboard with the "investigate" or "request patch" words. Targeting the bug to "3.0 P" implies the intention to produce an official patch for this bug. If it is later decided that this bug will not be fixed as an official patch, then it should be simply re-targeted to "3.0.1".

 

Nevertheless, we could use the whiteboard to determine the "solution type" of the official patch:

  - "update site" to release the official patch as a "feature patch" on the update site.

  - "rebuild plugin" to rebuild the patched plugin, so the adopter can simply include it in his product.

 

Does the above seem reasonable?

 

Regarding the "milestone cleanup". I doubt it is reasonable hiding certain milestones, if possible at all. While we want need most of them on the bug's page, we should have all of them displayed in the search page. However we could improve the situation by rearranging the sortkey of the milestones. So, the recent ones are on the top. I imagine something like this:

 

3.0 P

3.0.1

Future

--- (default)

3.0 RC4

3.0 RC3

.........

2.0.2 M202

2.0.1 M201

2.0 RC5

..........

2.0

1.5.5 M155

..........

 

The "---" milestone has the sortkey = "0". I think this makes it the default milestone. I have to check if negative sortkeys are possible, to milestones with negative sortkeys can pop above the "---" one.

 

An important note is that sortkeys of already created milestones cannot be changed by the Portal (I will file a bug about this), but only through are request to the webmaster.

 

Greetings,

Kaloyan

---

From: wtp-pmc-bounces@xxxxxxxxxxx [mailto:wtp-pmc-bounces@xxxxxxxxxxx] On Behalf Of raghunathan.srinivasan@xxxxxxxxxx
Sent: Thursday, June 19, 2008 1:11 AM
To: WTP PMC communications (including coordination, announcements, and Groupdiscussions)
Subject: RE: [wtp-pmc] Marking bugs for official patch

I vote for option1, a new target milestone for each patch ‘release’ for the corresponding official release.

 

---

From: David M Williams [mailto:david_williams@xxxxxxxxxx]
Sent: Wednesday, June 18, 2008 1:15 PM
To: WTP PMC communications (including coordination, announcements, and Group discussions)
Subject: Re: [wtp-pmc] Marking bugs for official patch

 

I think my preference would be number 1 and number 3 .... use the whiteboard to mark as "investigate" or "request patch", and then once patch produced, change to have a new target field. Even though few, still seems like the most consistent approach.

And ... if you're going to be working with the webmaster anyway ... I think it'd help the case for using a milestone target if we could "cleanup" the milestone target list.
I wonder if there is a way we can limit which of those are displayed ... so, old ones would not be displayed?

I think the "keyword" approach only makes sense if all projects at Eclipse wanted to use it ... not sure that would be the case here.

Thanks for pursuing this.

From:	"Raev, Kaloyan" <kaloyan.raev@xxxxxxx>
To:	"WTP PMC communications (including coordination, announcements,        and Group discussions)" <wtp-pmc@xxxxxxxxxxx>
Date:	06/18/2008 08:20 AM
Subject:	[wtp-pmc] Marking bugs for official patch

 

---

Hello,

We talked on the PMC call yesterday that we need a way to clearly mark
bugs that require to be released as an official patch.

I see three possible several possible ways to do this in Bugzilla.
 1. Target Milestone. A dedicated Target Milestone for each official
release that we provided official patches needs to be added. Example:
"3.0 P" or "3.0 PATCHES". We expect only few patches for a release.
Therefore creating a special Target Milestone does not seem reasonable.
 2. Keyword. A dedicated keyword can be to the bug. Example: "patch" or
"officialpatch". Adding keywords is a global bugzilla setting and should
be made by the webmaster.
 3. Whiteboard. A dedicated word can be added to the Whiteboard field.
Similar to the Keyword approach. We use the Whiteboard to mark bugs for
PMC approval. Typically, all "official patch" bugs should be approved by
the PMC. Therefore, we will always have overlapping in this field.
 4. Summary. A "[patch]" prefix can be added to the Summary of the bug.
We use this approach also for "hotbugs". Most of the "official patch"
bugs are also hotbugs. Overlapping could happen here as well.

For me the most reasonable approach is to mark the bugs with the keyword
"officialpatch" (option 2). If all of you are comfortable with this I
can request the webmaster to add this keyword to Bugzilla.

Greetings,
Kaloyan Raev
Eclipse WTP Committer
<http://www.eclipse.org/webtools/people/person.php?name=raev>
Senior Developer
NW C JS TOOLS JEE (BG)
SAP Labs Bulgaria
T +359/2/9157-416
mailto:kaloyan.raev@xxxxxxx
www.sap.com
P Save a tree - please do not print this email unless you really need
to!

_______________________________________________
wtp-pmc mailing list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc