[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [emf-dev] Maintenance Release Target Milestones
|
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@xxxxxxxxxxxxx <mailto:cdamus@xxxxxxxxxxxxx>
------------------------------------------------------------------------
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx <mailto:emf-dev@xxxxxxxxxxx>
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@xxxxxxxxxxxxx <mailto:cdamus@xxxxxxxxxxxxx>
------------------------------------------------------------------------
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
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@xxxxxxxxxxxxx
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev