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]
