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]
