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 <[EMAIL PROTECTED]>: > 2007/8/29, Tim Ellison <[EMAIL PROTECTED]>: > > > > Rana Dasgupta wrote: > > > On 8/27/07, Tim Ellison <[EMAIL PROTECTED]> 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 >
