harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: M4?
Date Thu, 18 Oct 2007 01:11:10 GMT
Before deciding on a duration, or posting plans on the Wiki, it may be
worthwhile to list some of the items that we want to do before the
next rollout...The duration would possibly fall out of that? With some
of these, we could either stretch the duration to whatever is adequate
if we want the feature, or branch the tree if we need to some time
before release. Here are some DRLVM features that would be good to
finish.

1. Improve 64 bit support ( eg., supporting heapsizes upto native
limit instead of compressed heaps only ), and enabling better
performance and code generation for compressed heaps. This is a
largish item.

2. Cocurrent GC. Xiao Feng could add some estimate of dev work, but
it's not small.

3. The threading changes that Weldon and Pavel Rebiry have been doing.
Another biggish item.

4. Class unloading needs no new work, other than bug fixes as we find them.

5. Some more work on magic classes? How much?

6. Some bugs/subfeature needs that have been sitting in JIRA for a
while, eg., non local lock inflation to unblock applications like
Resin

There are similarly, several classlibrary items, I am sure.

Thanks,
Rana



On 10/17/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Mikhail Loenko wrote:
> > It's interesting, but I've made for myself opposite conculsions from
> > the same facts :)
> >
> > Since we have a long stabilizing period it's good that we have a
> > longer milestone
> > cycle and thus we have less %% of freeze time
> >
> > As for M4, I think mid December or say, Friday Dec, 21 is OK (probably
> > we should try Dec 15-16 and have flexibility to extend it to Dec, 21)
>
> I suspect it is one of those topics that can be debated forever.  I'll
> try and explain my thinking, but realize it may not end up convincing
> you <g>.
>
> I'm an advocate of starting simply and getting things working, and
> keeping them working.  I think we do a good job of jumping on build
> breaks here, and breaks in some frequently run test suites.  So
> generally we don't drift too far away from some definition of 'working'.
>
> When things are working the next step (IMHO) is to release little and
> often.  I think there are a number of advantages including limiting the
> risk of diverging too far from working by making a number of significant
> changes simultaneously; establishing the developer mindset that the code
> is working so it must be my recent change that needs fixing; making a
> milestone release business as usual, so it is not a big deal if your
> feature misses this train, there will be another along soon;
> demonstrating progress to the outside world; and so on.
>
> Clearly there is a balance to be struck between very short iterations in
> which there is no time to develop significant new functionality, and
> very long iterations where the HEAD is a free for all that needs a long
> time to stabilize and deliver.  As a data point, Eclipse platform/JDT
> release milestones every six weeks.
>
> If you are going to get it wrong as you search for the optimal iteration
> time box, then I would suggest you want to go 'too short' rather than
> 'too long' since that will only serve to slow down forward progress
> rather than disrupt the working codebase and slow progress.
>
> Now let's not get things out of proportion.  We are debating a
> difference of only two weeks, nobody is suggesting order of magnitude
> differences, so I think there is room for compromise.
>
> Regards,
> Tim
>

Mime
View raw message