harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general] freeze for M5.5_Eclipse_TPTP
Date Thu, 24 Apr 2008 17:18:08 GMT
Mark,
Indeed, moving release date is another nice option we may consider.
What would be the earliest date for M6, indeed? Let's make a realistic
estimate, communicate it to Eclipse legals, and, indeed*, see how they
would react.

I'm also interested to hear arguments against a pseudo-release from you.
Thanks!

*) it's the third time he's used it


On Thu, Apr 24, 2008 at 8:50 PM, Mark Hindess
<mark.hindess@googlemail.com> wrote:
>
>  In message <6e47b64f0804240811ld143065v661469f11cba61ec@mail.gmail.com>,
>  "Stepan
>
> Mishura" writes:
>  >
>  > On 4/24/08, Mark Hindess <mark.hindess@googlemail.com> wrote:
>  > >
>  > > In message <480DC6F6.4000006@gmail.com>, Tim Ellison writes:
>  > > >
>  > > > I'm really not convinced this is a good idea for Harmony, and my
>  > > > concerns are in two parts:
>  > > >
>  > > > 1) Our schedule should not be dictated by an external project,
>  > > > especially when it is their process that seems to be setting the
>  > > > artificial time limit.  Why not show some flexibility to meet our
>  > > > dates?
>  > > >
>  > > > 2) Our principle delivery mechanism is source code.  While we make
>  > > > binaries available as a convenience we should not encourage dependents
>  > > > to put dependencies on our build tools.  They should take source and
>  > > > compile it themselves for their own environment.
>  > >
>  > > 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.
>  > >
>  >
>  > It makes me sad :-(
>
>  Sorry.
>
>
>  > We ask another project to be more flexible but we are not ready to be
>  > flexible too - we scheduled M6 to mid of May and we couldn't move it
>  > to the end of April.
>
>  That is unfair.  That is not what I've said.  I did not say we couldn't
>  move the M6 release date.  I've not stated an opinion on that one way
>  or the other.  However, my statement about "voting -1 for any formal
>  release that isn't simply the next milestone" was intended to allow for
>  this possibility.
>
>
>
>  > We are discussing the request almost for 2 weeks (this time is enough
>  > to make full milestone testing cycle) and I've not heard any strong
>  > argument for having it in mid of May expect that we scheduled it to
>  > this date. ;-(
>
>  Moving our milestone doesn't necessarily imply more work for everyone
>  while doing an extra release certainly does.  Hence I am more flexible
>  about the former.  The latter seems like another project forcing us to
>  do more work to get around their inflexible policy which is definitely
>  wrong to me.
>
>  I hope that is clearer and makes you a little less sad.
>
>  Regards,
>  -Mark.
>
>
>



-- 
With best regards,
Alexei

Mime
View raw message