harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk" <ilya.berezhn...@gmail.com>
Subject Re: [general] a real M6 (feature freeze today) Was: freeze for M5.5_Eclipse_TPTP
Date Fri, 25 Apr 2008 18:06:55 GMT
I would like to finish HARMONY-5617. Now the problem is just workarounded.

Although it's a bugfix, actually it includes changes in VM signal
handling to make it platform-independent, and moving stack and guard
page operations and OS-level threading to porting layer - so I think
it should be considered as a feature.

The patch is almost ready - I'm now investigating the last
intermittent problem with SIGUSR2 handling. Also I want to check
performance impact of the patch - this can take few days.

Thanks,
Ilya.

2008/4/25, Pavel Pervov <pmcfirst@gmail.com>:
> 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