Rich,
Shouldn’t 2.2 M2 be above 2.2 M1 in the list below?
Cheers,
Kenn
Hussey
Program Manager, EA/Studio
![[Embarcadero Technologies Logo]](jpgimq2e6g67R.jpg)
Embarcadero Technologies, Inc. | www.embarcadero.com
110 Spadina Avenue, Suite 400 | Toronto, ON
M5V 2K4
Kenn.Hussey@xxxxxxxxxxxxxxx
Mobile: 613-301-9105
From:
modeling-pmc-bounces@xxxxxxxxxxx [mailto:modeling-pmc-bounces@xxxxxxxxxxx] On
Behalf Of Richard Gronback
Sent: Thursday, June 19, 2008 12:57 PM
To: GMF Project developer discussions.
Cc: PMC members mailing list
Subject: [modeling-pmc] FW: [wtp-pmc] Marking bugs for official patch
A
popular topic, the maintenance of bugzilla target milestones. The
Modeling PMC recently discussed this and left it up to each project to do
what’s best for their particular needs.
Artem’s suggestion was to delete our old targets and update bugs to a single
release number (e.g. 1.0 M3 > 1.0) and insert a comment into the bug to
preserve the original target and allow searching, etc.
I think we can start with the rearrangement of sort key values, which like
David, I did not know was possible either.
For GMF, I’ll ask the webmaster to order such that the list appears as follows,
which should make the list easier to work with:
---
3.0
2.1.2
2.1.1
2.2
2.2 M1
2.2 M2
...
2.1
2.1 M1
...
Objections?
Thanks,
Rich
------ Forwarded Message
From: David M Williams <david_williams@xxxxxxxxxx>
Reply-To: "WTP PMC communications (including coordination,
announcements, and Group discussions)" <wtp-pmc@xxxxxxxxxxx>
Date: Thu, 19 Jun 2008 12:24:53 -0400
To: "WTP PMC communications (including coordination, announcements,
and Group discussions)" <wtp-pmc@xxxxxxxxxxx>
Subject: RE: [wtp-pmc] Marking bugs for official patch
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 <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 <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 <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 <mailto:kaloyan.raev@xxxxxxx>
www.sap.com
<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 <https://dev.eclipse.org/mailman/listinfo/wtp-pmc>
_______________________________________________
wtp-pmc mailing list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc <https://dev.eclipse.org/mailman/listinfo/wtp-pmc>
_______________________________________________
wtp-pmc mailing list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc
------ End of Forwarded Message