Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 209.85.128.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=jZiZiFfNZNKMrNOmmx8pbCSmFFYV0v3796m5FtJBiSe9sTKWRp7upKKIGMvB8P0+giS5gVMWWWeZ8PtK+xHFoaWqtf79CudjQwez2G3NUHyhhMBwNhL75gYHM8dY2VCTulAuqv8Oroov4njmeSpch87/pLHooV3Ffc4Dazvjx88=
Message-ID: <4715DF3F.3030603@gmail.com>
Date: Wed, 17 Oct 2007 11:09:03 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: M4?
References: <51d555c70710151035y6f0884bcx5d29a3fe065a684c@mail.gmail.com>
	 <4714CFF5.4070007@gmail.com>
	 <fc2fc95c0710160829v42485d68uf13f8611399a627c@mail.gmail.com>
 <906dd82e0710161920i758fdd2ax41f2f812d600ef47@mail.gmail.com>
In-Reply-To: <906dd82e0710161920i758fdd2ax41f2f812d600ef47@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Mikhail Loenko wrote:
> It's interesting, but I've made for myself opposite conculsions from
> the same facts :)
> 
> Since we have a long stabilizing period it's good that we have a
> longer milestone
> cycle and thus we have less %% of freeze time
> 
> As for M4, I think mid December or say, Friday Dec, 21 is OK (probably
> we should try Dec 15-16 and have flexibility to extend it to Dec, 21)

I suspect it is one of those topics that can be debated forever.  I'll
try and explain my thinking, but realize it may not end up convincing
you <g>.

I'm an advocate of starting simply and getting things working, and
keeping them working.  I think we do a good job of jumping on build
breaks here, and breaks in some frequently run test suites.  So
generally we don't drift too far away from some definition of 'working'.

When things are working the next step (IMHO) is to release little and
often.  I think there are a number of advantages including limiting the
risk of diverging too far from working by making a number of significant
changes simultaneously; establishing the developer mindset that the code
is working so it must be my recent change that needs fixing; making a
milestone release business as usual, so it is not a big deal if your
feature misses this train, there will be another along soon;
demonstrating progress to the outside world; and so on.

Clearly there is a balance to be struck between very short iterations in
which there is no time to develop significant new functionality, and
very long iterations where the HEAD is a free for all that needs a long
time to stabilize and deliver.  As a data point, Eclipse platform/JDT
release milestones every six weeks.

If you are going to get it wrong as you search for the optimal iteration
time box, then I would suggest you want to go 'too short' rather than
'too long' since that will only serve to slow down forward progress
rather than disrupt the working codebase and slow progress.

Now let's not get things out of proportion.  We are debating a
difference of only two weeks, nobody is suggesting order of magnitude
differences, so I think there is room for compromise.

Regards,
Tim