Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of t.p.ellison@gmail.com
 designates 72.14.220.158 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=rR1Xjz8DZQ19+GhenUDgEVWBF4WW7J3fJHNsx0ZGv0Kkbc06lesz34yju0EdmjqPknN8lboSewL/I4qAe2cyfTBvrmrKtIFvqKnWIEGrRygz7h/EwLSkEwNGaEjIfjjn/Wd31cT0CjHBZzYfahfJGKTQYZZ0KjK+fCgnklgYe7Y=
Message-ID: <4811AB4C.8030108@gmail.com>
Date: Fri, 25 Apr 2008 10:58:36 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [general] freeze for M5.5_Eclipse_TPTP
References: <14ecfd680804220324u15cf64c4w1d10274460553f6e@mail.gmail.com>
	 <480DC6F6.4000006@gmail.com>
	 <200804241029.m3OATsx5027776@d12av04.megacenter.de.ibm.com>
	 <481063C6.7050503@gmail.com>
 <6e47b64f0804240856s7b169871u15ab578445f8256d@mail.gmail.com>
In-Reply-To: <6e47b64f0804240856s7b169871u15ab578445f8256d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stepan Mishura wrote:
> On 4/24/08, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> Mark Hindess wrote:
>>> I agree with Tim on this issue.  I think making a release, with the
>>> testing, evaluation and voting involved, should not be something that
>>> downstream projects dictate.  Doing this release would seem to set a
>>> precedent that I would not be happy with.
>>>
>>> I would be inclined to vote -1 for any formal release that isn't simply
>>> the next milestone release.  Of course, this is not necessarily my final
>>> decision.
>>>
>>> The downstream project should use our current release or if they have
>>> a desperate need for something more recent then they should be more
>>> flexible.
>>>
>> Just to be clear about my views -- I have no objection if we choose to
>> effectively freeze new feature work in the verifier so that Eclipse can take
>> a copy of the source code at a well-defined revision number with some
>> assurance from us that it is not in a great state of flux.
>>
>> However, if we are going to produce a formal milestone, that has undergone
>> the testing, checking, signing, and distribution via ASF mirrors then we owe
>> it to all our users for that to be the best quality we can produce.  And
>> that means the feature freeze, code freeze, test and voting cycle that we
>> have established for the project.
>>
> 
> I don't know what particularly stands behind the 'officially released'
> requirement. We started our discussion with the requirement of 'binary
> release' and it transformed further to the 'source release'.

Our emphasis is on the source code.  The artifact that we vote upon as 
the release is the source bundle for our Milestone -- we are on open 
source project after all.  The binary builds are an important and 
sanctioned convenience to our users, but our mandate is to produce 
source not binaries.

> So say if we'll complete testing verifier and declare 'officially'
> that we tested it in particular svn revision that we freeze (i.e.
> verifier code) till M6 (and optionally provide a source bundle). Then
> IIUC it is OK for you but I don't know if it is acceptable for Eclipse
> project.

I meant we agree not to make any feature changes etc. in the verifier 
area knowing that Eclipse plan to pick up the code for TPTP, not that it 
remains frozen all the way to M6.

> And if the 'officially released' requirement implies our current
> formal process (i.e. testing, checking, voting, signing, distribution
> and so on) then I don't see any way how to resolve it in the current
> situation.

Let me make a concrete suggestion.

We feature freeze today, and start a code freeze on Mon 28th April.
We can expect testing and bug fixing to continue for at least one week, 
until Mon 5th May, then we have final vote and distribution probably 
taking until Fri 9th May.

The dates need to be flexible so if we find problems we will, as always, 
slip dates to get better quality.

What do you think?  A real M6, no arguments :-)

Regards,
Tim