|
»
»
»
»
»
Maintenance Release Target Milestones
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
Maintenance Release Target Milestones
by Christian W. Damus
::
Rate this Message:
Hi, all,
I have a follow-up problem on the subject of target milestones. I see that we have SR1 and SR2 milestones, now, which I suppose are meant for the targeting of bugs into the maintenance releases. However, this raises some questions:
Can we, perhaps, add generic milestones as follows, to solve both of these issues?
I'm not sure that the SR1 and SR2 milestones will be useful. Perhaps they could then be deleted. What do other EMF committers think of this? Thanks, Christian -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@... _______________________________________________ emf-dev mailing list emf-dev@... https://dev.eclipse.org/mailman/listinfo/emf-dev |
|
|
Re: Maintenance Release Target Milestones
by portal on behalf of Eike Stepper
::
Rate this Message:
Christian,
I always thought a clean solution would include separate target versions and generic target milestones. But I believe that this would require a broader discussion, if possible at all... Cheers /Eike ---- http://thegordian.blogspot.com Christian W. Damus schrieb: Hi, all, _______________________________________________ emf-dev mailing list emf-dev@... https://dev.eclipse.org/mailman/listinfo/emf-dev |
|
|
Re: Maintenance Release Target Milestones
by Christian W. Damus
::
Rate this Message:
Hi, Eike,
I agree. I would be happiest if Bugzilla had separate "Target Version" and "Target Milestone" fields, but alas, it does not. Of course, in that case, a "Ganymede x.y.2" target would be a target version, and not a milestone, but that would be fine. I thought that the problem was in the proliferation of version *numbers* in the target milestones, so that we had, for example, 2.4.1/1.2.1/1.0.1 all referring to the same maintenance release of different EMF components, where a single "Ganymede x.y.1" would suffice for the lot. However, now I am stuck with a bunch of bugs that were targeted for maintenance releases and are now targeted to "Past," and I have no sensible alternative in the current list of milestones. I just want to get back to conveying the same information in my bugs as they did last week. "Ganymede x.y.1" etc. is not a great solution, but it fits the current database schema and it would actually work. If anyone has a cleaner solution, please let me know! Thanks, Christian On 24-Nov-08, at 2:04 PM, Eike Stepper wrote:
-- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@... _______________________________________________ emf-dev mailing list emf-dev@... https://dev.eclipse.org/mailman/listinfo/emf-dev |
|
|
Re: Maintenance Release Target Milestones
by Nick Boldt
::
Rate this Message:
I'm down with the Ganymede x.y.1 idea, but I prefer Ganymede SR1 and SR2
to x.y.1 and x.y.2, since it better aligns with the train. True too, the SR2 build may include x.y.3, not .2, if an interim extra build was done (eg., GMF). That said I'll wait for Ed to weigh in when he gets back from his travels abroad. Nick Christian W. Damus wrote: > Hi, Eike, > > I agree. I would be happiest if Bugzilla had separate "Target > Version" and "Target Milestone" fields, but alas, it does not. Of > course, in that case, a "Ganymede x.y.2" target would be a target > version, and not a milestone, but that would be fine. > > I thought that the problem was in the proliferation of version > *numbers* in the target milestones, so that we had, for example, > 2.4.1/1.2.1/1.0.1 all referring to the same maintenance release of > different EMF components, where a single "Ganymede x.y.1" would > suffice for the lot. > > However, now I am stuck with a bunch of bugs that were targeted for > maintenance releases and are now targeted to "Past," and I have no > sensible alternative in the current list of milestones. I just want > to get back to conveying the same information in my bugs as they did > last week. > > "Ganymede x.y.1" etc. is not a great solution, but it fits the current > database schema and it would actually work. > > If anyone has a cleaner solution, please let me know! > > Thanks, > > Christian > > On 24-Nov-08, at 2:04 PM, Eike Stepper wrote: > >> Christian, >> >> I always thought a clean solution would include separate target >> versions and generic target milestones. >> But I believe that this would require a broader discussion, if >> possible at all... >> >> Cheers >> /Eike >> >> ---- >> http://thegordian.blogspot.com >> >> >> Christian W. Damus schrieb: >>> Hi, all, >>> >>> I have a follow-up problem on the subject of target milestones. >>> >>> I see that we have SR1 and SR2 milestones, now, which I suppose are >>> meant for the targeting of bugs into the maintenance releases. >>> However, this raises some questions: >>> >>> * how do I indicate which release stream >>> (Europa/Ganymede/Galileo) the maintenance fix is targeted at? >>> It doesn't make sense to use the flags because they are for >>> planning, and these fixes aren't planned. (besides, only >>> Galileo has a flag) >>> * my components have maintenance releases that line up with the >>> train SR1 and SR2, but also more releases in between. For >>> example, I had a 1.2.1 release before 1.2.2 which corresponded >>> with SR2. We could add, say, SR3 and SR4 milestones, but the >>> "SR" terminology suggests a correspondence with the train >>> timetable >>> >>> >>> Can we, perhaps, add generic milestones as follows, to solve both of >>> these issues? >>> >>> * Ganymede x.y.1 >>> * Ganymede x.y.2 >>> * Ganymede x.y.3 >>> * Galileo x.y.1 >>> * Galileo x.y.2 >>> * Galileo x.y.3 >>> >>> >>> I'm not sure that the SR1 and SR2 milestones will be useful. >>> Perhaps they could then be deleted. >>> >>> What do other EMF committers think of this? >>> >>> Thanks, >>> >>> Christian >>> >>> -- >>> Christian W. Damus >>> Senior Software Developer, Zeligsoft Inc. >>> Component Lead, Eclipse MDT OCL and EMF-QTV >>> E-mail: cdamus@... <mailto:cdamus@...> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> emf-dev mailing list >>> emf-dev@... >>> https://dev.eclipse.org/mailman/listinfo/emf-dev >>> >> >> _______________________________________________ >> emf-dev mailing list >> emf-dev@... <mailto:emf-dev@...> >> https://dev.eclipse.org/mailman/listinfo/emf-dev > > -- > Christian W. Damus > Senior Software Developer, Zeligsoft Inc. > Component Lead, Eclipse MDT OCL and EMF-QTV > E-mail: cdamus@... <mailto:cdamus@...> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > emf-dev mailing list > emf-dev@... > https://dev.eclipse.org/mailman/listinfo/emf-dev > -- Nick Boldt :: http://wiki.eclipse.org/User:Nickb Release Engineer :: Eclipse Modeling & Dash CBI _______________________________________________ emf-dev mailing list emf-dev@... https://dev.eclipse.org/mailman/listinfo/emf-dev |
|
|
Re: Maintenance Release Target Milestones
by Ed Merks-2
::
Rate this Message:
One might argue that SR1 always applies to the current service stream.
Who would ever fix bugs that target releases more than a year old? :-P Once that service stream is released, the target could be changed to the name of the release. I certainly don't see value in filling up the target list with a rapidly growing number of choices. Nick Boldt wrote: > I'm down with the Ganymede x.y.1 idea, but I prefer Ganymede SR1 and > SR2 to x.y.1 and x.y.2, since it better aligns with the train. True > too, the SR2 build may include x.y.3, not .2, if an interim extra > build was done (eg., GMF). > > That said I'll wait for Ed to weigh in when he gets back from his > travels abroad. > > Nick > > Christian W. Damus wrote: >> Hi, Eike, >> >> I agree. I would be happiest if Bugzilla had separate "Target >> Version" and "Target Milestone" fields, but alas, it does not. Of >> course, in that case, a "Ganymede x.y.2" target would be a target >> version, and not a milestone, but that would be fine. >> >> I thought that the problem was in the proliferation of version >> *numbers* in the target milestones, so that we had, for example, >> 2.4.1/1.2.1/1.0.1 all referring to the same maintenance release of >> different EMF components, where a single "Ganymede x.y.1" would >> suffice for the lot. >> >> However, now I am stuck with a bunch of bugs that were targeted for >> maintenance releases and are now targeted to "Past," and I have no >> sensible alternative in the current list of milestones. I just want >> to get back to conveying the same information in my bugs as they did >> last week. >> >> "Ganymede x.y.1" etc. is not a great solution, but it fits the >> current database schema and it would actually work. >> >> If anyone has a cleaner solution, please let me know! >> >> Thanks, >> >> Christian >> >> On 24-Nov-08, at 2:04 PM, Eike Stepper wrote: >> >>> Christian, >>> >>> I always thought a clean solution would include separate target >>> versions and generic target milestones. >>> But I believe that this would require a broader discussion, if >>> possible at all... >>> >>> Cheers >>> /Eike >>> >>> ---- >>> http://thegordian.blogspot.com >>> >>> >>> Christian W. Damus schrieb: >>>> Hi, all, >>>> >>>> I have a follow-up problem on the subject of target milestones. >>>> >>>> I see that we have SR1 and SR2 milestones, now, which I suppose are >>>> meant for the targeting of bugs into the maintenance releases. >>>> However, this raises some questions: >>>> >>>> * how do I indicate which release stream >>>> (Europa/Ganymede/Galileo) the maintenance fix is targeted at? >>>> It doesn't make sense to use the flags because they are for >>>> planning, and these fixes aren't planned. (besides, only >>>> Galileo has a flag) >>>> * my components have maintenance releases that line up with the >>>> train SR1 and SR2, but also more releases in between. For >>>> example, I had a 1.2.1 release before 1.2.2 which corresponded >>>> with SR2. We could add, say, SR3 and SR4 milestones, but the >>>> "SR" terminology suggests a correspondence with the train >>>> timetable >>>> >>>> >>>> Can we, perhaps, add generic milestones as follows, to solve both >>>> of these issues? >>>> >>>> * Ganymede x.y.1 >>>> * Ganymede x.y.2 >>>> * Ganymede x.y.3 >>>> * Galileo x.y.1 >>>> * Galileo x.y.2 >>>> * Galileo x.y.3 >>>> >>>> >>>> I'm not sure that the SR1 and SR2 milestones will be useful. >>>> Perhaps they could then be deleted. >>>> >>>> What do other EMF committers think of this? >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> -- >>>> Christian W. Damus >>>> Senior Software Developer, Zeligsoft Inc. >>>> Component Lead, Eclipse MDT OCL and EMF-QTV >>>> E-mail: cdamus@... <mailto:cdamus@...> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> emf-dev mailing list >>>> emf-dev@... >>>> https://dev.eclipse.org/mailman/listinfo/emf-dev >>>> >>> >>> _______________________________________________ >>> emf-dev mailing list >>> emf-dev@... <mailto:emf-dev@...> >>> https://dev.eclipse.org/mailman/listinfo/emf-dev >> >> -- >> Christian W. Damus >> Senior Software Developer, Zeligsoft Inc. >> Component Lead, Eclipse MDT OCL and EMF-QTV >> E-mail: cdamus@... <mailto:cdamus@...> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> emf-dev mailing list >> emf-dev@... >> https://dev.eclipse.org/mailman/listinfo/emf-dev >> > emf-dev mailing list emf-dev@... https://dev.eclipse.org/mailman/listinfo/emf-dev |
|
|
Re: Maintenance Release Target Milestones
by Christian W. Damus
::
Rate this Message:
Hi, Ed,
That implies more bug administration: at the "end" of the maintenance branch (when is that?), we change all of the SRx milestone targets to indicate that the bug was actually targeted for the GA release? That doesn't make sense. As I understand it, the goal for the EMF and EMFT projects is to promote all of their components to projecthood by Galileo, right? Then, we will all have a rational line-up of milestones that we can maintain separately and according to the version numbers that are current for us. So, how about, until then, we accept a small number of additional shared milestones so that those of us who care about being able to accurately reflect a bug's history can do that? The choices won't grow at all after Galileo. Thanks, Christian On 26-Nov-08, at 2:41 AM, Ed Merks wrote: > One might argue that SR1 always applies to the current service > stream. Who would ever fix bugs that target releases more than a > year old? :-P Once that service stream is released, the target > could be changed to the name of the release. > > I certainly don't see value in filling up the target list with a > rapidly growing number of choices. > > > Nick Boldt wrote: >> I'm down with the Ganymede x.y.1 idea, but I prefer Ganymede SR1 >> and SR2 to x.y.1 and x.y.2, since it better aligns with the train. >> True too, the SR2 build may include x.y.3, not .2, if an interim >> extra build was done (eg., GMF). >> >> That said I'll wait for Ed to weigh in when he gets back from his >> travels abroad. >> >> Nick >> >> Christian W. Damus wrote: >>> Hi, Eike, >>> >>> I agree. I would be happiest if Bugzilla had separate "Target >>> Version" and "Target Milestone" fields, but alas, it does not. Of >>> course, in that case, a "Ganymede x.y.2" target would be a target >>> version, and not a milestone, but that would be fine. >>> >>> I thought that the problem was in the proliferation of version >>> *numbers* in the target milestones, so that we had, for example, >>> 2.4.1/1.2.1/1.0.1 all referring to the same maintenance release of >>> different EMF components, where a single "Ganymede x.y.1" would >>> suffice for the lot. >>> >>> However, now I am stuck with a bunch of bugs that were targeted >>> for maintenance releases and are now targeted to "Past," and I >>> have no sensible alternative in the current list of milestones. I >>> just want to get back to conveying the same information in my bugs >>> as they did last week. >>> >>> "Ganymede x.y.1" etc. is not a great solution, but it fits the >>> current database schema and it would actually work. >>> >>> If anyone has a cleaner solution, please let me know! >>> >>> Thanks, >>> >>> Christian >>> >>> On 24-Nov-08, at 2:04 PM, Eike Stepper wrote: >>> >>>> Christian, >>>> >>>> I always thought a clean solution would include separate target >>>> versions and generic target milestones. >>>> But I believe that this would require a broader discussion, if >>>> possible at all... >>>> >>>> Cheers >>>> /Eike >>>> >>>> ---- >>>> http://thegordian.blogspot.com >>>> >>>> >>>> Christian W. Damus schrieb: >>>>> Hi, all, >>>>> >>>>> I have a follow-up problem on the subject of target milestones. >>>>> >>>>> I see that we have SR1 and SR2 milestones, now, which I suppose >>>>> are meant for the targeting of bugs into the maintenance >>>>> releases. However, this raises some questions: >>>>> >>>>> * how do I indicate which release stream >>>>> (Europa/Ganymede/Galileo) the maintenance fix is targeted at? >>>>> It doesn't make sense to use the flags because they are for >>>>> planning, and these fixes aren't planned. (besides, only >>>>> Galileo has a flag) >>>>> * my components have maintenance releases that line up with the >>>>> train SR1 and SR2, but also more releases in between. For >>>>> example, I had a 1.2.1 release before 1.2.2 which >>>>> corresponded >>>>> with SR2. We could add, say, SR3 and SR4 milestones, but the >>>>> "SR" terminology suggests a correspondence with the train >>>>> timetable >>>>> >>>>> >>>>> Can we, perhaps, add generic milestones as follows, to solve >>>>> both of these issues? >>>>> >>>>> * Ganymede x.y.1 >>>>> * Ganymede x.y.2 >>>>> * Ganymede x.y.3 >>>>> * Galileo x.y.1 >>>>> * Galileo x.y.2 >>>>> * Galileo x.y.3 >>>>> >>>>> >>>>> I'm not sure that the SR1 and SR2 milestones will be useful. >>>>> Perhaps they could then be deleted. >>>>> >>>>> What do other EMF committers think of this? >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> >>>>> -- >>>>> Christian W. Damus >>>>> Senior Software Developer, Zeligsoft Inc. >>>>> Component Lead, Eclipse MDT OCL and EMF-QTV >>>>> E-mail: cdamus@... <mailto:cdamus@...> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> emf-dev mailing list >>>>> emf-dev@... >>>>> https://dev.eclipse.org/mailman/listinfo/emf-dev >>>>> >>>> >>>> _______________________________________________ >>>> emf-dev mailing list >>>> emf-dev@... <mailto:emf-dev@...> >>>> https://dev.eclipse.org/mailman/listinfo/emf-dev >>> >>> -- >>> Christian W. Damus >>> Senior Software Developer, Zeligsoft Inc. >>> Component Lead, Eclipse MDT OCL and EMF-QTV >>> E-mail: cdamus@... <mailto:cdamus@...> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> emf-dev mailing list >>> emf-dev@... >>> https://dev.eclipse.org/mailman/listinfo/emf-dev >>> >> > _______________________________________________ > emf-dev mailing list > emf-dev@... > https://dev.eclipse.org/mailman/listinfo/emf-dev -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@... _______________________________________________ emf-dev mailing list emf-dev@... https://dev.eclipse.org/mailman/listinfo/emf-dev |
|
|
Re: Maintenance Release Target Milestones
by Ed Merks-2
::
Rate this Message:
Christian,
Comments below. Christian W. Damus wrote: > Hi, Ed, > > That implies more bug administration: at the "end" of the maintenance > branch (when is that?), we change all of the SRx milestone targets to > indicate that the bug was actually targeted for the GA release? That > doesn't make sense. Sounds like it could be automated though. > > As I understand it, the goal for the EMF and EMFT projects is to > promote all of their components to projecthood by Galileo, right? When the foundation's infrastructures supports it, yes. > Then, we will all have a rational line-up of milestones that we can > maintain separately and according to the version numbers that are > current for us. Yes more more shuffling... > So, how about, until then, we accept a small number of additional > shared milestones so that those of us who care about being able to > accurately reflect a bug's history can do that? The choices won't > grow at all after Galileo. I'm not thrilled with that approach. I suppose you'll argue that setting the version in which you've fixed it isn't good enough either... (The MDT targets are still a mess. It would be nice if it worked the same way.) > > Thanks, > > Christian > > > On 26-Nov-08, at 2:41 AM, Ed Merks wrote: > >> One might argue that SR1 always applies to the current service >> stream. Who would ever fix bugs that target releases more than a >> year old? :-P Once that service stream is released, the target >> could be changed to the name of the release. >> >> I certainly don't see value in filling up the target list with a >> rapidly growing number of choices. >> >> >> Nick Boldt wrote: >>> I'm down with the Ganymede x.y.1 idea, but I prefer Ganymede SR1 and >>> SR2 to x.y.1 and x.y.2, since it better aligns with the train. True >>> too, the SR2 build may include x.y.3, not .2, if an interim extra >>> build was done (eg., GMF). >>> >>> That said I'll wait for Ed to weigh in when he gets back from his >>> travels abroad. >>> >>> Nick >>> >>> Christian W. Damus wrote: >>>> Hi, Eike, >>>> >>>> I agree. I would be happiest if Bugzilla had separate "Target >>>> Version" and "Target Milestone" fields, but alas, it does not. Of >>>> course, in that case, a "Ganymede x.y.2" target would be a target >>>> version, and not a milestone, but that would be fine. >>>> >>>> I thought that the problem was in the proliferation of version >>>> *numbers* in the target milestones, so that we had, for example, >>>> 2.4.1/1.2.1/1.0.1 all referring to the same maintenance release of >>>> different EMF components, where a single "Ganymede x.y.1" would >>>> suffice for the lot. >>>> >>>> However, now I am stuck with a bunch of bugs that were targeted for >>>> maintenance releases and are now targeted to "Past," and I have no >>>> sensible alternative in the current list of milestones. I just >>>> want to get back to conveying the same information in my bugs as >>>> they did last week. >>>> >>>> "Ganymede x.y.1" etc. is not a great solution, but it fits the >>>> current database schema and it would actually work. >>>> >>>> If anyone has a cleaner solution, please let me know! >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> On 24-Nov-08, at 2:04 PM, Eike Stepper wrote: >>>> >>>>> Christian, >>>>> >>>>> I always thought a clean solution would include separate target >>>>> versions and generic target milestones. >>>>> But I believe that this would require a broader discussion, if >>>>> possible at all... >>>>> >>>>> Cheers >>>>> /Eike >>>>> >>>>> ---- >>>>> http://thegordian.blogspot.com >>>>> >>>>> >>>>> Christian W. Damus schrieb: >>>>>> Hi, all, >>>>>> >>>>>> I have a follow-up problem on the subject of target milestones. >>>>>> >>>>>> I see that we have SR1 and SR2 milestones, now, which I suppose >>>>>> are meant for the targeting of bugs into the maintenance >>>>>> releases. However, this raises some questions: >>>>>> >>>>>> * how do I indicate which release stream >>>>>> (Europa/Ganymede/Galileo) the maintenance fix is targeted at? >>>>>> It doesn't make sense to use the flags because they are for >>>>>> planning, and these fixes aren't planned. (besides, only >>>>>> Galileo has a flag) >>>>>> * my components have maintenance releases that line up with the >>>>>> train SR1 and SR2, but also more releases in between. For >>>>>> example, I had a 1.2.1 release before 1.2.2 which corresponded >>>>>> with SR2. We could add, say, SR3 and SR4 milestones, but the >>>>>> "SR" terminology suggests a correspondence with the train >>>>>> timetable >>>>>> >>>>>> >>>>>> Can we, perhaps, add generic milestones as follows, to solve both >>>>>> of these issues? >>>>>> >>>>>> * Ganymede x.y.1 >>>>>> * Ganymede x.y.2 >>>>>> * Ganymede x.y.3 >>>>>> * Galileo x.y.1 >>>>>> * Galileo x.y.2 >>>>>> * Galileo x.y.3 >>>>>> >>>>>> >>>>>> I'm not sure that the SR1 and SR2 milestones will be useful. >>>>>> Perhaps they could then be deleted. >>>>>> >>>>>> What do other EMF committers think of this? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Christian >>>>>> >>>>>> -- >>>>>> Christian W. Damus >>>>>> Senior Software Developer, Zeligsoft Inc. >>>>>> Component Lead, Eclipse MDT OCL and EMF-QTV >>>>>> E-mail: cdamus@... <mailto:cdamus@...> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> emf-dev mailing list >>>>>> emf-dev@... >>>>>> https://dev.eclipse.org/mailman/listinfo/emf-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> emf-dev mailing list >>>>> emf-dev@... <mailto:emf-dev@...> >>>>> https://dev.eclipse.org/mailman/listinfo/emf-dev >>>> >>>> -- >>>> Christian W. Damus >>>> Senior Software Developer, Zeligsoft Inc. >>>> Component Lead, Eclipse MDT OCL and EMF-QTV >>>> E-mail: cdamus@... <mailto:cdamus@...> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> emf-dev mailing list >>>> emf-dev@... >>>> https://dev.eclipse.org/mailman/listinfo/emf-dev >>>> >>> >> _______________________________________________ >> emf-dev mailing list >> emf-dev@... >> https://dev.eclipse.org/mailman/listinfo/emf-dev > > -- > Christian W. Damus > Senior Software Developer, Zeligsoft Inc. > Component Lead, Eclipse MDT OCL and EMF-QTV > E-mail: cdamus@... > > > > _______________________________________________ > emf-dev mailing list > emf-dev@... > https://dev.eclipse.org/mailman/listinfo/emf-dev emf-dev mailing list emf-dev@... https://dev.eclipse.org/mailman/listinfo/emf-dev |
|
|
Re: Maintenance Release Target Milestones
by Nick Boldt
::
Rate this Message:
> One might argue that SR1 always applies to the current service stream.
Not if you combine it with the galileo+ flag. If you want to know what bugs are targeted for Galileo and within that, targeted for its SR1 or RC2 or M4, use the galileo+ flag and the appropriate target milestone. Simple enough? That way there's no need to move anything at the end of a release, and all the admin that's required year-over-year is to add a new flag and a new milestone for the next train name. As to the morasse that is MDT Target Milestones... talk to Kenn. I can work w/ the webmasters to clean up what's there, but I'll need bugzilla admin access and for that I need the PMC of that project to first empower me. Of course the hardest part is getting agreement re: workflow -- the rest is just administrivia. :) N On Wed, Nov 26, 2008 at 9:37 AM, Ed Merks <ed.merks@...> wrote: Christian, -- Nick Boldt :: JBoss, a division of Red Hat Productization Lead :: JBoss Tools & Dev Studio Release Engineer :: Eclipse Modeling & Dash CBI http://wiki.eclipse.org/User:Nickb _______________________________________________ emf-dev mailing list emf-dev@... https://dev.eclipse.org/mailman/listinfo/emf-dev |
|
|
RE: Re: Maintenance Release Target Milestones
by Kenn Hussey
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Regarding MDT target milestones, the only thing I would consider
at this point is removal of version-specific milestones (e.g., 1.1 M1, etc.);
these have obvious mappings to their version-agnostic counterparts (as opposed
to PAST or FUTURE). However, since new products will be created in Bugzilla for
MDT components when they become projects, and since most (if not all) open MDT bugs
are already using the version-agnostic milestones (e.g., M1, etc.), I don’t see
a burning need for the churn at this point… Cheers, Kenn
Hussey
Embarcadero Technologies, Inc. | www.embarcadero.com From:
emf-dev-bounces@... [mailto:emf-dev-bounces@...] On Behalf
Of Nick Boldt > One might argue that SR1
always applies to the current service stream. |
![[Embarcadero Technologies Logo]](http://www.nabble.com/attachment/20712157/0/image001.jpg)