harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Spark Shen" <smallsmallor...@gmail.com>
Subject Re: M4?
Date Fri, 19 Oct 2007 02:16:36 GMT
2007/10/19, Mark Hindess <mark.hindess@googlemail.com>:
> 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.

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

Spark Shen
China Software Development Lab, IBM

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