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

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

Reply via email to