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
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
|