[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [wtp-pmc] Marking bugs for official patch
|
Yes, we can change sortkeys by requesting the webmaster.
This bug is an example how to do it:
Now I see that in the main bug page that not all of
the WTP milestones a shown in the combo box. In the same time all of the
milestones are available in the search page. Then, it seems that we could really
request the webmaster to hide some of the oldest milestones.
Where do we want to draw the line? Hide everything up to
milestone 1.5.5 including (if patches for 1.5.5 are needed, they should be
targeted to the "1.5.5 P")?
What do we do with milestone 4.0? Do we hide it, too, until
we have plans for WTP 4.0?
Greetings,
Kaloyan
Changing the sort order is a good
idea. (I didn't know we could!). As
for "hiding" some from the display ... to be clear, I did mean the very old
ones, and I did mean just on the combo box where committers assign the milestone
target. If you meant "too hard for
webmasters to do" ... then, oh, ok ... I wouldn't know about that (but seems
like a nice feature request :) thanks for handling this.
| From:
| "Raev, Kaloyan"
<kaloyan.raev@xxxxxxx>
|
| To:
| "WTP PMC communications (including
coordination, announcements, and Group
discussions)" <wtp-pmc@xxxxxxxxxxx>
|
| Date:
| 06/19/2008 12:10 PM
|
| Subject:
| RE: [wtp-pmc] Marking bugs for official
patch |
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
_______________________________________________
wtp-pmc mailing
list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc
