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]
