harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [general] freeze for M5.5_Eclipse_TPTP
Date Thu, 24 Apr 2008 16:50:35 GMT

In message <6e47b64f0804240811ld143065v661469f11cba61ec@mail.gmail.com>, 
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 :-(

> 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.


View raw message