harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Paulex" <paulex.y...@gmail.com>
Subject Re: [general] Defining M3
Date Wed, 29 Aug 2007 10:44:57 GMT
2007/8/29, Tim Ellison <t.p.ellison@gmail.com>:
>
> Rana Dasgupta wrote:
> > On 8/27/07, Tim Ellison <t.p.ellison@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message