harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [general] a real M6 (feature freeze today) Was: freeze for M5.5_Eclipse_TPTP
Date Fri, 25 Apr 2008 14:22:49 GMT
Well, I would like to unify types used in external interfaces with
those used in class library (hycomp.h).

These changes are pretty simple, but widespread. There are series to
patches: one type unification per patch. If the code freeze is now -
then I have to wait for two weeks to commit the changes. I'd like to
do it before the freeze.

Thanks,
    Pavel.

On 4/25/08, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> 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
>


-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

Mime
View raw message