harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: M4?
Date Thu, 18 Oct 2007 20:28:06 GMT

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