harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [general] M3 milestone discussion
Date Wed, 22 Aug 2007 12:50:25 GMT
Tim, here is the description of my problems with 2-mo schedule:
Usually I spent a half of my time to work on bugs or testing, reviewing and
committing various JIT patches. Another
half of my time I'm trying to develop new features. Writing code for new
features is not an issue: but performance and regression
testing consumes most of the time.
When I'm limited by a short time period and I want new feature to be
included to the next release I need to hurry and as a result I reduce the
time for testing and documentation.
For example in M2 milestone we were not able to turn "lazy resolution"
feature on because we didn't have enough time to test it. We turned it on in
the first week after codebase was unfrozen.

I agree with Salikh and others who says that we need stable schedule.
But what is the reason for official milestones that are so frequent that
have no differences from each other?

On 8/22/07, Salikh Zakirov <salikh@gmail.com> wrote:
> Tim Ellison wrote:
> > Weldon Washburn wrote:
> >> How about move
> >> M3 to the end of September?  This will give us a few weeks to discuss
> >> what should (and should not) go into M3.
> >
> > The content of M3 is whatever is in SVN at the point we declare it
> > stable.  If there is code that is misbehaving then we would take it out
> > to achieve stability across the codebase.  IMHO extending the period to
> > decide what is in it doesn't make sense.
> FWIW, I think that keeping 2-month cycle is better for the project.
> For an external observer, postponing the release schedule will most likely
> mean that either
> (1) SVN trunk has serious stability problems, or
> (2) development stalled and no differences from M3 are there to warrant a
> new release
> To my knowledge, both are not true, and neither is the message we would
> want
> to send to the world.
> As I reasoned elsewhere, I think the most beneficial strategy for Harmony
> project
> now would be release _officially_ (rather than doing developer snapshots)
> and keep to the schedule,
> so as the distributions could start including Harmony into the 'unstable'
> areas.

Mikhail Fursov

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