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 stepan.mishura@gmail.com
 designates 209.85.146.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Ae7SBigidkKnk4slZ4JuwrfcI7uGDQaDbBxENbq3Cnlx+xvW9WpkUYOqewvpesMja0E1RHdl59d6l90diMwjPa7+GdaIxeRwW4eJ14Uzcw5bNdYyDJ+NznIWVf3CmDKV9OhrnfqwO9hb2hbdDBJV5DL1asvKeqom8p0SBy9Blis=
Message-ID: <6e47b64f0804240811ld143065v661469f11cba61ec@mail.gmail.com>
Date: Thu, 24 Apr 2008 22:11:42 +0700
From: "Stepan Mishura" <stepan.mishura@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general] freeze for M5.5_Eclipse_TPTP
In-Reply-To: <200804241029.m3OATsx5027776@d12av04.megacenter.de.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <14ecfd680804220324u15cf64c4w1d10274460553f6e@mail.gmail.com>
	 <480DC6F6.4000006@gmail.com>
	 <200804241029.m3OATsx5027776@d12av04.megacenter.de.ibm.com>

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

Thanks,
Stepan.

> Regards,
>  Mark.
>
>
>