Re: [gmf-dev] Re: [modeling-pmc] FW: [wtp-pmc] Marking bugs for official

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [gmf-dev] Re: [modeling-pmc] FW: [wtp-pmc] Marking bugs for official patch

From: Anthony Hunter <anthonyh@xxxxxxxxxx>
Date: Thu, 19 Jun 2008 15:25:16 -0400
Delivered-to: gmf-dev@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/private/gmf-dev>
List-help: <mailto:gmf-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/gmf-dev>, <mailto:gmf-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/listinfo/gmf-dev>, <mailto:gmf-dev-request@eclipse.org?subject=unsubscribe>

Agreed.

Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager: Eclipse Open Source Components
IBM Rational Software: Aurora / GMF / Modeling Tools
Phone: 613-270-4613

Richard Gronback ---06/19/2008 03:21:00 PM---[restricting to just GMF list] And you¹re OK with losing old target milestones that may be used for

From:	Richard Gronback <richard.gronback@xxxxxxxxxxx>
To:	"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
Date:	06/19/2008 03:21 PM
Subject:	[gmf-dev] Re: [modeling-pmc] FW: [wtp-pmc] Marking bugs for official patch

[restricting to just GMF list]

And you’re OK with losing old target milestones that may be used for searching? The only place I can think these are used is in our plan documents, where links are provided for each release by milestone. I doubt anyone is actively searching on previous release milestones, and they can always change their search criteria to look for a comment like the following, which I’ll propose be entered during the process:

[target cleanup] 2.1 M3 was the original target milestone for this bug

(or similar)

Thanks,
Rich

On 6/19/08 12:51 PM, "Anthony Hunter" <anthonyh@xxxxxxxxxx> wrote:

> we can go with Artem’s recommendation of simply merging old releases and keeping the list in simple sequential order.

1+ to this recommendation. The list will be short again and can be in simple sequential order.

I can help with these as I will do the same exercise with GEF.

Cheers...
Anthony
--
Anthony Hunter

mailto:anthonyh@xxxxxxxxxx

Software Development Manager: Eclipse Open Source Components
IBM Rational Software: Aurora / GMF / Modeling Tools
Phone: 613-270-4613

Richard Gronback ---06/19/2008 02:35:55 PM---> Now different eclipse projects will have different rules and numerical orders in Bugzilla? Not sma

From:

Richard Gronback <

richard.gronback@xxxxxxxxxxx

To:

PMC members mailing list <

modeling-pmc@xxxxxxxxxxx

Cc:

"GMF Project developer discussions." <

gmf-dev@xxxxxxxxxxx

Date:

06/19/2008 02:35 PM

Subject:

Re: [modeling-pmc] FW: [wtp-pmc] Marking bugs for official patch

> Now different eclipse projects will have different rules and numerical orders in Bugzilla? Not smart.

An interesting statement. Not only is there no standard way (afaik) that target milestones and sort keys are assigned now, it’s clear from a quick look at Bugzilla that there are already different rules and numerical orders being used today. The reason is that sort keys and the target milestone string itself is entered through the portal by the project lead, or designate.

The main point of the exercise is to bring the most relevant/likely target milestones to near the top of the list. The reason I put the order the way I did was to put the next cycle’s milestones in increasing order, and after the next maintenance releases (which arguably should have been listed 2.1.1 then 2.1.2). I put 3.0 near the top to make it easy to push off items to the next main api-breaking release, but could easily have put it at the bottom below all the prior releases/milestones. So, let me try again:

---
2.1.1
2.1.2
2.2
2.2 M1
2.2 M2
...
2.1
2.1 M1
...
3.0

> We are going to remove the old milestones like 2.1 M1 too (I think).

Not remove, but simply reorder at the bottom of the list. Alternatively, if everyone thinks this reordering exercise is too confusing or problematic, we can go with Artem’s recommendation of simply merging old releases and keeping the list in simple sequential order.

At a minimum, now that I know we can, I’d like to have the webmaster adjust our sort keys to fix some errors I made in picking sort keys in the past (in case you never noticed).

- Rich

On 6/19/08 11:54 AM, "Anthony Hunter" <

anthonyh@xxxxxxxxxx

> > wrote:

Hi Rich,

Kenn's reply pretty much gives tips off what we should be doing, it should be numerical order, anything else just creates confusion. If we are proposing changing the order, all projects at Eclipse should be doing the same thing. Now different eclipse projects will have different rules and numerical orders in Bugzilla? Not smart.

---
3.0
2.2 M2
2.2 M1
2.2
2.1.2
2.1.1
2.1
...

or

...
2.1
2.1.1
2.1.2
2.2
2.2 M1
2.2 M2
...
3.0

We are going to remove the old milestones like 2.1 M1 too (I think).

Cheers...
Anthony
--
Anthony Hunter

mailto:anthonyh@xxxxxxxxxx

>
Software Development Manager: Eclipse Open Source Components
IBM Rational Software: Aurora / GMF / Modeling Tools
Phone: 613-270-4613

"Kenn Hussey" ---06/19/2008 01:36:45 PM---Rich,

From:

"Kenn Hussey" <

Kenn.Hussey@xxxxxxxxxxxxxxx

> >

To:

"PMC members mailing list" <

modeling-pmc@xxxxxxxxxxx

> >, "GMF Project developer discussions." <

gmf-dev@xxxxxxxxxxx

> >

Date:

06/19/2008 01:36 PM

Subject:

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

Rich,

Shouldn’t 2.2 M2 be above 2.2 M1 in the list below?

Cheers,

Kenn Hussey
Program Manager, EA/Studio

http://www.embarcadero.com/

> >

Embarcadero Technologies, Inc. |

www.embarcadero.com

http://www.embarcadero.com/

> >

110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4

Kenn.Hussey@xxxxxxxxxxxxxxx

Kenn.Hussey@xxxxxxxxxxxxxxx

> <

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

> <

david_williams@xxxxxxxxxx

> > >

Reply-To:

"WTP PMC communications (including coordination, announcements, and Group discussions)" <

wtp-pmc@xxxxxxxxxxx

> <

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

> <

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

> <

kaloyan.raev@xxxxxxx

> > >

To:

"WTP PMC communications (including coordination, announcements, and Group discussions)" <

wtp-pmc@xxxxxxxxxxx

> <

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

> <

wtp-pmc-bounces@xxxxxxxxxxx

> >

[

mailto:wtp-pmc-bounces@xxxxxxxxxxx

> <

mailto:wtp-pmc-bounces@xxxxxxxxxxx

> > <

mailto:wtp-pmc-bounces@xxxxxxxxxxx

> <

mailto:wtp-pmc-bounces@xxxxxxxxxxx

> > >

]

On Behalf Of

raghunathan.srinivasan@xxxxxxxxxx

> <

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

> > <

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

> <

kaloyan.raev@xxxxxxx

> > >

To:

"WTP PMC communications (including coordination, announcements, and Group discussions)" <

wtp-pmc@xxxxxxxxxxx

> <

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

> > <

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