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 alexei.fedotov@gmail.com
 designates 209.85.200.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=meWiB3eo1YKfkAorjPnTdYBPxgUENC9m3Dq0dMvTUCSd05QgAn6eVQoBH/kHffbQ3mSFZzXmhdh0hPjoEkehiyoFFxBsk0ax6PM/XqKbisluhAabuNNTPFuaImouzHhbRV4lu2aPweiElkcBHzPwiHpRyoIce+sZeuJQjIKjwwE=
Message-ID: <c30d70960804250351j4fdf7f9endf8da32581046404@mail.gmail.com>
Date: Fri, 25 Apr 2008 14:51:06 +0400
From: "Alexei Fedotov" <alexei.fedotov@gmail.com>
To: dev@harmony.apache.org
Subject: [general] a real M6 (feature freeze today) Was: freeze for
 M5.5_Eclipse_TPTP
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

All,
Please pay attention to the suggestion of making a feature freeze
today for incoming M6. Does anyone has features in progress we may
want to include into M6 release? Please, speak up.

It is important to understand if the suggestion is timely for harmony
developers.
Thank you.

On Fri, Apr 25, 2008 at 1:58 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>
> 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
>


-- 
With best regards,
Alexei