Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[gmf-dev] Re: [modeling-pmc] FW: [wtp-pmc] Marking bugs for official patch
Title: 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 <anthonyh@xxxxxxxxxx> > wrote:

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

Back to the top