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]
