From dev-return-29007-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Mon Sep 03 15:30:53 2007
Return-Path:
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 12091 invoked from network); 3 Sep 2007 15:30:52 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 3 Sep 2007 15:30:52 -0000
Received: (qmail 66570 invoked by uid 500); 3 Sep 2007 15:30:45 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 66262 invoked by uid 500); 3 Sep 2007 15:30:44 -0000
Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@harmony.apache.org
Delivered-To: mailing list dev@harmony.apache.org
Received: (qmail 66253 invoked by uid 99); 3 Sep 2007 15:30:44 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Sep 2007 08:30:44 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of alexey.a.petrenko@gmail.com designates 64.233.182.185 as permitted sender)
Received: from [64.233.182.185] (HELO nf-out-0910.google.com) (64.233.182.185)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Sep 2007 15:30:41 +0000
Received: by nf-out-0910.google.com with SMTP id 30so1225252nfu
for ; Mon, 03 Sep 2007 08:30:19 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
d=gmail.com; s=beta;
h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
b=atFyiLHoVged3jcCBBxmEDSnAWVM/BxX2XyJ4b8fj2O4uV3MUHm5MERTiXWw3+p/9OQobV5sTPUlKs1VKDV5fx3zD6nCM+TAYDNjtpIV/te4Tnk65Cc4obzPdArVWzL+wxxgE+KI23O4NbtF/CNPXClSi5QFlVQ7hxfBu/5T9+0=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
b=lnhTHt8fUtEIyPHukQeLVypkQFCu8GU0hSa3PfCA2MSZdZwUr5K40ETyPGxjBzQIFpnlxdCovZ9jguhi0/VGslKV97ZGTOZrIiue6nIK5hmpSA93e2HmeRS+LebPVW6jAVqwbN29C2s9WICQ63piTazTy92fveAPTwwnKQ0uBio=
Received: by 10.86.93.17 with SMTP id q17mr3510202fgb.1188833419192;
Mon, 03 Sep 2007 08:30:19 -0700 (PDT)
Received: by 10.86.30.8 with HTTP; Mon, 3 Sep 2007 08:30:19 -0700 (PDT)
Message-ID:
Date: Mon, 3 Sep 2007 19:30:19 +0400
From: "Alexey Petrenko"
To: dev@harmony.apache.org
Subject: Re: [general] Defining M3
In-Reply-To:
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <46D2ECFD.5090909@gmail.com>
<51d555c70708271557j1c12f6d2md0b2dbca951a1192@mail.gmail.com>
<46D53C11.3040506@gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org
I like the idea of branching and freezing the branch instead of trunk.
And yes, we need release notes.
SY, Alexey
2007/8/29, Yang Paulex :
> 2007/8/29, Tim Ellison :
> >
> > Rana Dasgupta wrote:
> > > On 8/27/07, Tim Ellison wrote:
> > >> We've had some discussion, I think it is time to agree on whether we
> > are
> > >> going to shoot for a M3 release soon or let things ride for a while
> > longer.
> > >
> > > We should shoot for an M3 release sometime soon. Whether that means
> > > freezing new feature code immediately and focussing on bugs, or
> > > continuing till around mid September before freezing, depends on who
> > > is doing what, and how the unfinished work impacts stability.
> >
> > Given the lack of participants in the discussion it would appear that
> > people are away, or don't really mind what happens, or something.
> >
> > At the risk of repeating myself, I think it is important to have regular
> > and predictable milestones available; enabling those people who to
> > consume Harmony to be able to plan on taking future stable builds.
> >
> > It's also important for us to be able to deliver the code as a coherent
> > set of functionality.
> >
> > > Some of
> > > the features that I know of, in development currently in DRLVM are
> > > concurrent GC, a lot of thread restructuring, class unloading support
> > > and a bunch of JIT changes. For class unloading, a little more time
> > > would be great. So I would vote for the later date.
> >
> > There is always going to be work in progress, we have to learn to
> > schedule it around the agreed stability points. If it isn't delivered
> > it doesn't count .
> >
> > An alternative alternative is to split the GC / JIT / classlib / VM /
> > tools etc into separate deliverables and we assemble milestones from the
> > last stable build from each 'subproject'. But I don't want to go in
> > that direction, I hope we can continue to co-ordinate the development as
> > one big project.
> >
> > Let's make good the code that we have in the mainline builds before
> > starting another lengthy piece of work.
>
>
> Some wild thoughts in the Milestone build:
>
> 1. Milestone tag - tags/branches on SVN is pretty lightweight, so there's no
> reason not to utilize them. IIRC someone complained before there is no easy
> way to get the source code for Harmony milestone build, so hopefully from
> this time, we can create the tag for milestone build in SVN, and let others
> know about it. It's also great to make the src tar ball for downloading with
> binaries.
>
> 2. Release notes - (maybe not an appropriate name for a milestone build, but
> anyway), hopefully we can get some description with the milestone build,
> including the new features/defects fixed (I guess there's some way to
> extract this kind of stuffs from svn log automatically... I'm happy to
> create a script if there's no existing tools), installation guide, known
> limitations, etc, etc...IMHO not everyone would like to have a try without a
> basic understanding of our real progress (the API coverage is obviously far
> from enough)
>
> 3. Milestone definition time, I'm not sure if it's a good idea trying to
> define the objectives at the beginning of every iteration (the duration
> between milestone builds) instead of at two weeks before the end date,
> which can make the situation more foreseeable and mitigate the risk to
> delay.
>
> 4. Code freeze phase, seems 2 weeks frozen is a little too long for
> someones, but even not enough for others, so again I'm going to propose
> tags/branches solution on this, i.e., if we think some revision is "almost"
> ready to ship as milestone build, we create a branch for it as MC(Milestone
> Candidate) and freeze the branch instead of whole svn repository, then some
> guys may focus on the stability testing/bug fixing for the MC, and others go
> on for the new features. And of course when the MC finally becomes
> MB(Milestone Build), some work is needed to merge them, but from the
> experience of last two milestones, I suppose there won't be no much
> conflicts.
>
> Back to the M3 definition, on the classlib part, currently in my radar,
> there's at least one significant NIO defects need to be fixed(HARMONY-4081)
> , besides some providers are missing in Harmony like LDAP
> provider/Kerberos/rowset impl/sound provider, etc, but almost all of them
> are big chunk of work and I don't believe they can be completed before M3.
>
> Regards,
> > Tim
> >
>
>
>
> --
> Paulex Yang
> China Software Development laboratory
> IBM
>