harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Paulex" <paulex.y...@gmail.com>
Subject Re: [general] Discussion: how to keep up stability and fast progress all together?
Date Mon, 02 Apr 2007 07:25:11 GMT
+1 from me on milestones, if with which a developer release will be
delivered.

Especially seems someone are going to start Java 6 work, with the same
concern with Stepan, I preferred to release at least once on Java 5 API
level before we heads into substantial Java 6 upgrade.

2007/3/30, Tim Ellison <t.p.ellison@gmail.com>:
>
> Stepan Mishura wrote:
> > We made a big progress in improving the project's code base. Just for
> > example, a total number of excluded tests in the class library were
> > reduced by ~ 60 entries in two months. Also taking into account that
> > Windows x86_64 build was enabled and the test suite is growing I think
> > this is a good progress indicator for the Class library. The same for
> > DRL VM – new testing modes are added and a total number of excluded
> > tests for most of modes are reducing. Let's keep up good progress!
> >
> > But I'd like to attract attention to stability issues. I've been
> > monitoring CC status for a couple of months and I my impression that
> > situation with stability become worse – a number of reports about
> > failures is growing. I'm afraid that if we set keeping good stability
> > aside then it may affect the overall project's progress.
> >
> > I'd like to encourage everybody to pay attention to stability side and
> > to hear ideas how to improve the situation?
>
> Caveat:  I'm still 200 emails behind on the dev list, a good sign of the
> project's liveliness, but my apologies in advance for any repetition...
>
> IMO we won't achieve rock solid stability without focusing on it as an
> explicit goal; and delivering a Milestone release is the best way to get
> that focus.
>
> Not exactly a novel or radical idea, but Milestones have a number of
> benefits not least of which is that they demonstrate we, as a diverse
> group, can converge on a delivery of the code we are working on.  Some
> projects will rumble on forever without committing to a stable, tested,
> and likely imperfect, packaging of something.
>
> If the Milestones are time-boxed they also form a natural boundary for
> feature planning, and afford some predictability to the project that is
> also important.
>
> In my experience, something like 6 to 8 weeks between Milestones is a
> good period of time.  Four weeks is too short to get big ticket items in
> and stable, and 12 weeks (a quarter year) is too long such that
> instability can set-in.
>
> In that 6 to 8 week period there should be a time at the end where we
> hold back from introducing cool new function, and emphasize testing and
> fixing.  Maybe that is the last seven days leading up to the Milestone,
> and of course, if instability exists we slip the date until we can
> declare a stable point.
>
> I read the discussion on naming, and M1, M2, ... is fine by me.  How
> about we pick a proposed date for Apache Harmony M1?
>
> Regards,
> Tim
>



-- 
Paulex Yang
China Software Development laboratory
IBM
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message