Re: [general] Defining M3

[Alexey Petrenko <al...@gmail.com>]

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 <pa...@gmail.com>:
> 2007/8/29, Tim Ellison <t....@gmail.com>:
> >
> > Rana Dasgupta wrote:
> > > On 8/27/07, Tim Ellison <t....@gmail.com> 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 <g>.
> >
> > 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
>