Hello Tom!
I hope that I (or perhaps someone else) will eventually come round to
documenting this procedure. All we have is the very terse description at
the top of the release plan page
http://argouml.tigris.org/project_schedule.html and the description of
how P1 and P2 issues are handled in the Cookbook
(http://argouml-stats.tigris.org/documentation/defaulthtml/cookbook/ch09
s02.html#issue_priorities). For previous releases I was more explicit
about the bug fixes only, regression fixes only but I missed that one
this time.
I will go for Bob's suggestion and replace the second alpha with the
first beta if all P2 issues are solved quickly enough.
/Linus
> -----Original Message-----
> From: Tom Morris [mailto:[EMAIL PROTECTED]
> Sent: den 13 juni 2006 19:53
> To: [email protected]
> Subject: RE: [argouml-dev] Upcoming releases - the path towards 0.22
>
> Thanks for driving us towards a plan. Hopefully everyone is already
> focused
> on getting 0.22 out the door, so the official declaration of alpha
status
> shouldn't really change much.
>
> I know last time there were a number of misunderstandings (including
by
> me)
> about what the different statuses mean. I can't find it documented
> anywhere, but I think the following is what I finally came to
understand.
> Is this still accurate?
>
> Alpha:
> entry criteria: 0 P1 problems, no failing tests, unlimited P2 and
lower
> priority problems
> code changes allowed: bug fixes only
>
> Beta:
> entry criteria: 0 P1 and 0 P2 problems, no failing tests, unlimited
P3
> and
> lower priority problems
> code changes allowed: only fixes to regressions introduced during
beta
>
> Of the 11 P2 problems currently open, 3 are likely to get closed as
> unreproduceable (4165, 4184, 4212) and several others a likely
> misprioritized, so I don't think we're actually as far away as it
might
> seem
> from getting a testable release ready for beta.
>
> Tom
>
> > -----Original Message-----
> > From: Linus Tolke [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 13, 2006 12:49 PM
> > To: [email protected]
> > Subject: RE: [argouml-dev] Upcoming releases - the path towards 0.22
> >
> >
> > So, to sum up in this matter...
> >
> > Michiel is concerned that the release will disturb his and
> > Andrea's work. There is a big risk it will. I have suggested
> > some ways to reduce the impact.
> >
> > Bob wants to go ahead as planned and suggests deemphasizing
> > the preset dates in favor of a more consequential planning.
> >
> > There are 11 P2 issues.
> >
> >
> > I don't consider this a clear consensus either way so I will
> > go ahead as planned then and make the first alpha release
> > tonight. I will start the release work in an hour or so.
> > After that point we have entered the alpha-stage so after
> > that no enhancements are to be entered into 0.22.
> >
> > /Linus
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Linus Tolke [mailto:[EMAIL PROTECTED]
> > > Sent: den 13 juni 2006 07:53
> > > To: [email protected]
> > > Subject: RE: [argouml-dev] Upcoming releases - the path towards
0.22
> > >
> > > Hello Bob!
> > >
> > > Well, yes, this is the plan.
> > >
> > > You have stated how to go through the release phases in a
> > very clear
> > > way. I will eventually put this into the Cookbook or somewhere. I
> > > consider the betas to be more or less release candidates and don't
> > plan
> > > to have three different "kinds" of release before the stable
release
> > but
> > > just two.
> > >
> > > However it doesn't address the issue of how to shorten this
> > procedure
> > > that I was aiming at.
> > >
> > > I will come back to this tonight.
> > >
> > > /Linus
> > >
> > > > -----Original Message-----
> > > > From: Bob Tarling [mailto:[EMAIL PROTECTED]
> > > > Sent: den 13 juni 2006 02:42
> > > > To: [email protected]
> > > > Subject: Re: [argouml-dev] Upcoming releases - the path
> > towards 0.22
> > > >
> > > > How about this.
> > > >
> > > > We go to alpha at some agreed time providing we have no
> > P1 issues.
> > > > Alpha is only for our testing or those testing with
> > knowledge of the
> > > > bug status..
> > > >
> > > > During the alpha phase we may discover more P1 and P2 defects.
We
> > > > should do no subsequent alpha if we have outstanding P1
> > issues. We
> > > > should only be fixing those defects at P1/P2. We do a new
> > alpha once
> > > > we have no more P1's.
> > > >
> > > > We shouldn't go to beta until we feel confident that the
> > users have
> > > > something robust to test. So we go to beta once we have
> > no P1 or P2
> > > > issues.
> > > >
> > > > During the beta phase we may once again discover more P1 and P2
> > > > defects and only release another beta when they are all fixed.
> > > >
> > > > Once a beta results in no new issues then we should make
> > a release.
> > > > But first a release candidate.
> > > >
> > > > Once again we can make subsequent RC releases until we get no
> > further
> > > > P1/P2 defects reported back to us.
> > > >
> > > > The last RC can then be promoted to a release with no effective
> > change
> > > > other than its packaging.
> > > >
> > > > At any stage we can discuss whether any issues that are of lower
> > > > priority should be promoted to a higher priority. I think
> > there are
> > > > often cases that a more minor issue could be an
> > embarassment in a
> > > > major release.
> > > >
> > > > Bob.
> > > >
> > > > On 6/12/06, Linus Tolke <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hello Michiel!
> > > > >
> > > > >
> > > > >
> > > > > I'd say there is no way to prevent this. We can't have both
> > activity
> > > and
> > > > > stability at the same time.
> > > > >
> > > > >
> > > > >
> > > > > There are several possibilities for this. If the work
> > Andrea does
> > is
> > > > > distinct issues, then each patch can wait and be applied
later.
> > That
> > > is
> > > > > inconvenient for you because there will be a big
> > integration later
> > > on.
> > > > You
> > > > > can commit all of your work (yours and Andrea's) in a
> > branch that
> > > you
> > > > are
> > > > > maintaining to do most of the integration work incrementally
but
> > > that is
> > > > > inconvenient because your commits will end up on the cvs
mailing
> > > list
> > > > and
> > > > > there is a risk of confusion and the integration still has to
> > happen
> > > if
> > > > > someone else has done work. Also the tools (the daily build
...)
> > are
> > > set
> > > > up to
> > > > > work on the main branch and you won't be able to use
> > that because
> > we
> > > > want to
> > > > > use them for the main release.
> > > > >
> > > > >
> > > > >
> > > > > Above, I mentioned the risk of confusion. Another way to look
at
> > > this is
> > > > > from the project group focus perspective. I would hope that
> > everyone
> > > > > (including you and Andrea) would work mainly on the
> > issues of the
> > > > release
> > > > > i.e. we focus together on the release. That would result in
two
> > > things.
> > > > > Firstly, you will help the release work hopefully making the
> > release
> > > > period
> > > > > shorter and the quality of the release better and secondly,
you
> > will
> > > be
> > > > busy
> > > > > with focusing on the release work so the amount of work you
are
> > able
> > > to
> > > > do
> > > > > that will not go into the release is smaller and
consequentially
> > the
> > > > > integration problem smaller.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I think the best way to generally reduce this kind of
> > problems is
> > to
> > > > shorten
> > > > > the alpha/beta period. Theoretically this can be done
> > by reducing
> > > the
> > > > amount
> > > > > of things that shall happen during the alpha/beta
> > period and there
> > > is
> > > > > actually one thing that we can do while still keep our
> > options and
> > > the
> > > > > ability to do other improvements open. I am thinking
> > about the 13
> > P2
> > > > > defects. These shall all be addressed during the alpha
> > period. If
> > > they
> > > > are
> > > > > resolved before we enter the alpha period, the alpha
> > period can be
> > > that
> > > > much
> > > > > shorter. This is of course not possible without risking that
the
> > > > eventual
> > > > > 0.22 release will be delayed more than otherwise but I
> > am willing
> > to
> > > > risk
> > > > > that (it could also have the opposite effect). It is
> > hard to plan
> > > this
> > > > kind
> > > > > of things because the times don't add and divide as expected.
> > Shall
> > > we
> > > > set
> > > > > out a new goal that there shall only be 1 or 2 unresolved P2
> > defects
> > > > when we
> > > > > enter alpha and remove the second alpha-release (so we just
have
> > > one)?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I will give you all until tomorrow (evening) to think
> > this through
> > > and
> > > > > respond. This will defer the first alpha one day just
> > for the sake
> > > of
> > > > > discussing. Let's hope that we all keep the work with the P2
> > issues
> > > up
> > > > no
> > > > > matter what.
> > > > >
> > > > >
> > > > >
> > > > > /Linus
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > >
> > > > >
> > > > > From: Michiel van der Wulp [mailto:[EMAIL PROTECTED]
> > > > > Sent: den 12 juni 2006 16:23
> > > > >
> > > > > To: [email protected]
> > > > > Subject: Re: [argouml-dev] Upcoming releases - the path
towards
> > > 0.22
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hi Linus,
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > There is one problem: I'd like to continue working with
> > Andrea for
> > > the
> > > > > Google SOC in the same way:
> > > > >
> > > > >
> > > > > Andrea attaches a patch to an issue (defect or
> > enhancement) and I
> > > check
> > > > and
> > > > > commit.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Starting alpha releases now, would block this -
> > initially only for
> > > > > enhancements, later also for defects.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Is there a way to prevent this?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On the other hand, if there is no way around, then the
> > sooner the
> > > better
> > > > > (and limited to a short period, too).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > >
> > > > > Michiel
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > >
> > > > >
> > > > > From: Linus Tolke
> > > > >
> > > > >
> > > > > To: [email protected]
> > > > >
> > > > >
> > > > > Sent: Monday, June 12, 2006 12:13 AM
> > > > >
> > > > >
> > > > > Subject: [argouml-dev] Upcoming releases - the path towards
0.22
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hello all!
> > > > >
> > > > >
> > > > >
> > > > > I just created an announcement for the 0.21.3 release. I have
> > sadly
> > > > > neglected to write announcements for the past releases.
> > > > >
> > > > >
> > > > >
> > > > > The plan is to now, soon (tomorrow or actually today), enter
the
> > > alpha
> > > > phase
> > > > > before the 0.22 release. The beginning of the alpha phase
means
> > that
> > > no
> > > > more
> > > > > enhancements or changes will go into the 0.22 release, just
> > defects
> > > > fixed.
> > > > >
> > > > >
> > > > >
> > > > > Are we ready for this?
> > > > >
> > > > >
> > > > >
> > > > > I noticed that there is one P1 defect, the issue 4256. It is a
> > > blocker
> > > > also
> > > > > for the 0.22.alpha1 release so that will have to be
> > fixed. We then
> > > have
> > > > 14
> > > > > P2 defects. All of them will have to be fixed before we enter
> > > beta-state.
> > > > >
> > > > >
> > > > >
> > > > > Our options are:
> > > > >
> > > > > Go ahead tomorrow and start working with the intensive
> > alpha/beta
> > > > release
> > > > > schedule towards 0.22.
> > > > > Put the 0.22.alpha1 off for a couple of days.
> > > > > Introduce a 0.21.4 release in 2 weeks deferring the
> > alpha/beta and
> > > 0.22
> > > > > releases about 3 weeks. Notice that if there are too many P2
> > defects
> > > > that we
> > > > > don't solve in time for the betas, then the release will be
> > deferred
> > > > anyway.
> > > > > We need to have the "right amount" before leaving the
> > 0.21 release
> > > suite.
> > > > >
> > > > >
> > > > >
> > > > > What shall we do? It all comes down to how much work is left
to
> > get
> > > 0.22
> > > > in
> > > > > shape. If I am to make the release 0.22.alpha1
> > tomorrow, I will do
> > > it on
> > > > the
> > > > > evening so we have around 19 hours to decide this before I go
> > ahead
> > > and
> > > > > embark on the first option.
> > > > >
> > > > >
> > > > >
> > > > > Let me know where you think we are and what we should do.
> > > > >
> > > > >
> > > > >
> > > > > /Linus
> > > > >
> > > > >
> > > > >
> > > > >
> > *******************************************************************
> > > > >
> > > > > Linus Tolke
> > > > > [EMAIL PROTECTED] [EMAIL PROTECTED]
> > > > >
> > *******************************************************************
> > > > >
> > > > >
> > > > > ________________________________
> > > > >
> > > > >
> > > > > No virus found in this incoming message.
> > > > > Checked by AVG Free Edition.
> > > > > Version: 7.1.394 / Virus Database: 268.8.3/361 - Release
Date:
> > > > 11/06/2006
> > > > >
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
