M4?

[Rana Dasgupta <rd...@gmail.com>]

Hi,
  Are we continuing our current 3 month release cycles for an M4
rollout in December? If so, would the code freeze date for this be mid
December? Are folks available around at this time? It would help to
decide this upfront.
 If we are, it may make sense to list what we want to achieve in this
cycle and post it on the Wiki, so that come release time, we can make
decisions based on completeness as well as stability.

Thanks,
Rana

Re: M4?

[Rana Dasgupta <rd...@gmail.com>]

On 10/18/07, Tim Ellison <t....@gmail.com> wrote:
> Rana Dasgupta wrote:
> > 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.
>
> I would suggest it is optimistic to attempt to stabilize three+ major
> pieces of work in a single iteration.

  They look like a lot, I agree :-) but 2 out of 3 have been in
development for some time. These are not new items as such. The 64 bit
heap support is.
>
> Any reason why class unloading should not be default on now?

Yes, no reason at all. HARMONY-4931 switches it on.
>
> Regards,
> Tim
>
>

Re: M4?

[Tim Ellison <t....@gmail.com>]

Rana Dasgupta wrote:
> 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.

I would suggest it is optimistic to attempt to stabilize three+ major
pieces of work in a single iteration.

Any reason why class unloading should not be default on now?

Regards,
Tim

Re: M4?

[Weldon Washburn <we...@gmail.com>]

On 10/17/07, Rana Dasgupta <rd...@gmail.com> wrote:
> 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.

I am neutral on M4 date.  Of course we will try to get Thread State
Transition code committed before M4 code freeze.  If it does not
happen, I am happy to wait until M5.

Re: M4?

[Spark Shen <sm...@gmail.com>]

2007/10/19, Mark Hindess <ma...@googlemail.com>:
>
>
> On 17 October 2007 at 18:11, "Rana Dasgupta" <rd...@gmail.com> wrote:
> >
> > 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.
>
> I agree the items you mention would be good to finish but I don't agree
> that M4 should wait for any of them.
>
> I am strongly against any attempt to "stretch the duration" of
> milestones to allow time to complete features.  As you suggest, if
> features can't be completed (or disabled) for the creation of a stable
> milestone release then they can be developed on a branch.
>
> I think the length of the freeze this time around was a direct result of
> the long time between M2 and M3.  I'd be in favour of shorter milestone
> release cycles.
>
> I don't believe that having shorter release cycles leads to a greater
> percentage of time with the code base frozen (as I think Mikhail
> suggested in an earlier message on this thread).  It might do initially
> but in the long term it should mean that we remain closer to release
> readiness all the time.


Not quite sure about this. The only way to find the result is to do and see.


Longer release cycles mean that there is a tendency to let standards
> drop between releases and justify it by saying it will be fixed before
> the next release.  For example, poor test coverage (perhaps due to new
> code) when the reality is that having poor test coverage leads to "poor"
> code because no one will have the confidence to be able to dive in and
> (learn to) improve it[0].
>
> Weldon recently wrote:
>
>   we will try to get Thread State Transition code committed before M4
>   code freeze.  If it does not happen, I am happy to wait until M5.
>
> I like this attitude because it means we will get good code when it is
> ready rather than hurried code in time for a milestone.
>
> It is easier to encourage people to take this attitude - "wait until
> the next milestone" - if the time between milestone is well-defined and
> relatively short.  "If my code doesn't make it in, then at least I don't
> have to wait long for the next opportunity for integration/fame."


+1. If we make mile stone release schedule on a regular time scale but not a
regular feature scale,
IMO, people may tend to focus more on the code quality of the already
committed code but not to commit
new features in a hurry - which bring no great help to harmony's quality. On
the other hand,
we, developers will feel less pressure on event such as the mile stone. It
may further do some potential help.

Short release cycles are better for our users because they get simple
> bug fixes integrated into a "stable" build sooner rather than having to
> wait until some arbitrary large item that they may not need is ready.
> For example, suppose someone using x86 is waiting on a fix for the
> anti-aliased fonts on Linux (which has been integrated in svn[1]).
> I don't see why they should have to wait until, for example, x86_64
> support is ready[2].
>
> Of course, this last advantage will disappear if/when we make full
> releases that we'll support with bugfixes made on a branch.  Then full
> releases could be further apart though I'm still not sure I'd want them
> to be.
>
> So let's decide on a date - and I think Tim's suggestion is a reasonable
> compromise though personally I'd prefer it shorter - and then decide
> what we can get done in that time.
>
> Regards,
> Mark.
>
> [0] I had a trivial improvement for JpegEncode.c but the code was not
>     covered by a test case so I haven't make the change (yet).  Perhaps
>     I will write a test case eventually if someone hasn't got there
>     already.
>
> [1] I know it isn't actually complete but it was the first example I
>     thought of.  It isn't really a "simple fix" either so it is a bad
>     example.
>
> [2] This is also a bad example because progress seems to be being made
>     pretty fast on this one - which is excellent.
>
> > On 10/17/07, Tim Ellison <t....@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
>
>
>


-- 
Spark Shen
China Software Development Lab, IBM

Re: M4?

[Mark Hindess <ma...@googlemail.com>]

On 17 October 2007 at 18:11, "Rana Dasgupta" <rd...@gmail.com> wrote:
>
> 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.

I agree the items you mention would be good to finish but I don't agree
that M4 should wait for any of them.

I am strongly against any attempt to "stretch the duration" of
milestones to allow time to complete features.  As you suggest, if
features can't be completed (or disabled) for the creation of a stable
milestone release then they can be developed on a branch.

I think the length of the freeze this time around was a direct result of
the long time between M2 and M3.  I'd be in favour of shorter milestone
release cycles.

I don't believe that having shorter release cycles leads to a greater
percentage of time with the code base frozen (as I think Mikhail
suggested in an earlier message on this thread).  It might do initially
but in the long term it should mean that we remain closer to release
readiness all the time.

Longer release cycles mean that there is a tendency to let standards
drop between releases and justify it by saying it will be fixed before
the next release.  For example, poor test coverage (perhaps due to new
code) when the reality is that having poor test coverage leads to "poor"
code because no one will have the confidence to be able to dive in and
(learn to) improve it[0].

Weldon recently wrote:

  we will try to get Thread State Transition code committed before M4
  code freeze.  If it does not happen, I am happy to wait until M5.

I like this attitude because it means we will get good code when it is
ready rather than hurried code in time for a milestone.

It is easier to encourage people to take this attitude - "wait until
the next milestone" - if the time between milestone is well-defined and
relatively short.  "If my code doesn't make it in, then at least I don't
have to wait long for the next opportunity for integration/fame."

Short release cycles are better for our users because they get simple
bug fixes integrated into a "stable" build sooner rather than having to
wait until some arbitrary large item that they may not need is ready.
For example, suppose someone using x86 is waiting on a fix for the
anti-aliased fonts on Linux (which has been integrated in svn[1]).
I don't see why they should have to wait until, for example, x86_64
support is ready[2].

Of course, this last advantage will disappear if/when we make full
releases that we'll support with bugfixes made on a branch.  Then full
releases could be further apart though I'm still not sure I'd want them
to be.

So let's decide on a date - and I think Tim's suggestion is a reasonable
compromise though personally I'd prefer it shorter - and then decide
what we can get done in that time.

Regards,
 Mark.

[0] I had a trivial improvement for JpegEncode.c but the code was not
    covered by a test case so I haven't make the change (yet).  Perhaps
    I will write a test case eventually if someone hasn't got there
    already.

[1] I know it isn't actually complete but it was the first example I
    thought of.  It isn't really a "simple fix" either so it is a bad
    example.

[2] This is also a bad example because progress seems to be being made
    pretty fast on this one - which is excellent.

> On 10/17/07, Tim Ellison <t....@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

Re: M4?

[Rana Dasgupta <rd...@gmail.com>]

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....@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
>

Re: M4?

[Tim Ellison <t....@gmail.com>]

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

Re: M4?

[Mikhail Loenko <ml...@gmail.com>]

2007/10/16, Sian January <si...@googlemail.com>:
> On 16/10/2007, Tim Ellison <t....@gmail.com> wrote:
> >
> > Rana Dasgupta wrote:
> > >   Are we continuing our current 3 month release cycles for an M4
> > > rollout in December? If so, would the code freeze date for this be mid
> > > December? Are folks available around at this time? It would help to
> > > decide this upfront.
> >
> > It's a good time to reflect on the M3 experiences, and see if/how we
> > want to tweak things.
> >
> > IMHO the code was frozen a little longer than ideal.  We considered
> > moving the stable code onto a branch and re-open HEAD, but that was
> > probably going to be too heavyweight for a milestone build.
> >
> > I've said before that shorter cycles are my preference.  I agree there
> > is a fixed overhead for testing, but I believe part of the extended M3
> > experience was due to the amount of new code that needed testing and
> > fixing, and the regressions that we needed to catch-up on, etc.
>
>
> I agree with Tim here.  There were over 400 bugs fixed / new features
> between M2 and M3, which seems like an awful lot of code to be testing all
> at once.  It also makes it harder to track down what code caused what error
> etc.  Given the size of our community and the rate at which code goes in I
> think shorter release cycles would make more sense.

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)

Thanks,
Mikhail

>
> As you say, three months from the M3 would put things right into the
> > December/January holiday period for many people.  I suggest that we make
> > M4 a short cycle, e.g. freeze at the end of November and release
> > mid-December, rather than push things out further into the new year.
> >
> > This would not only be practical at this time of year, but will also
> > give us a data point for the short cycle milestone plan, from which we
> > can make a decision about M5 etc.
>
>
> +1
>
> >  If we are, it may make sense to list what we want to achieve in this
> > > cycle and post it on the Wiki, so that come release time, we can make
> > > decisions based on completeness as well as stability.
> >
> > Absolutely.  All the items that were deferred from M3, like class
> > unloading, should be on that list.  How about we agree on a date then
> > get a wiki page going?  (Our roadmap could do with a visit too ;-/ )
> >
> > Regards,
> > Tim
> >
>
>
> Sian
> --
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>

Re: M4?

[Sian January <si...@googlemail.com>]

On 16/10/2007, Tim Ellison <t....@gmail.com> wrote:
>
> Rana Dasgupta wrote:
> >   Are we continuing our current 3 month release cycles for an M4
> > rollout in December? If so, would the code freeze date for this be mid
> > December? Are folks available around at this time? It would help to
> > decide this upfront.
>
> It's a good time to reflect on the M3 experiences, and see if/how we
> want to tweak things.
>
> IMHO the code was frozen a little longer than ideal.  We considered
> moving the stable code onto a branch and re-open HEAD, but that was
> probably going to be too heavyweight for a milestone build.
>
> I've said before that shorter cycles are my preference.  I agree there
> is a fixed overhead for testing, but I believe part of the extended M3
> experience was due to the amount of new code that needed testing and
> fixing, and the regressions that we needed to catch-up on, etc.


I agree with Tim here.  There were over 400 bugs fixed / new features
between M2 and M3, which seems like an awful lot of code to be testing all
at once.  It also makes it harder to track down what code caused what error
etc.  Given the size of our community and the rate at which code goes in I
think shorter release cycles would make more sense.

As you say, three months from the M3 would put things right into the
> December/January holiday period for many people.  I suggest that we make
> M4 a short cycle, e.g. freeze at the end of November and release
> mid-December, rather than push things out further into the new year.
>
> This would not only be practical at this time of year, but will also
> give us a data point for the short cycle milestone plan, from which we
> can make a decision about M5 etc.


+1

>  If we are, it may make sense to list what we want to achieve in this
> > cycle and post it on the Wiki, so that come release time, we can make
> > decisions based on completeness as well as stability.
>
> Absolutely.  All the items that were deferred from M3, like class
> unloading, should be on that list.  How about we agree on a date then
> get a wiki page going?  (Our roadmap could do with a visit too ;-/ )
>
> Regards,
> Tim
>


Sian
-- 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: M4?

[Tim Ellison <t....@gmail.com>]

Rana Dasgupta wrote:
>   Are we continuing our current 3 month release cycles for an M4
> rollout in December? If so, would the code freeze date for this be mid
> December? Are folks available around at this time? It would help to
> decide this upfront.

It's a good time to reflect on the M3 experiences, and see if/how we
want to tweak things.

IMHO the code was frozen a little longer than ideal.  We considered
moving the stable code onto a branch and re-open HEAD, but that was
probably going to be too heavyweight for a milestone build.

I've said before that shorter cycles are my preference.  I agree there
is a fixed overhead for testing, but I believe part of the extended M3
experience was due to the amount of new code that needed testing and
fixing, and the regressions that we needed to catch-up on, etc.

As you say, three months from the M3 would put things right into the
December/January holiday period for many people.  I suggest that we make
M4 a short cycle, e.g. freeze at the end of November and release
mid-December, rather than push things out further into the new year.

This would not only be practical at this time of year, but will also
give us a data point for the short cycle milestone plan, from which we
can make a decision about M5 etc.

>  If we are, it may make sense to list what we want to achieve in this
> cycle and post it on the Wiki, so that come release time, we can make
> decisions based on completeness as well as stability.

Absolutely.  All the items that were deferred from M3, like class
unloading, should be on that list.  How about we agree on a date then
get a wiki page going?  (Our roadmap could do with a visit too ;-/ )

Regards,
Tim