harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [general] Harmony M2 schedule
Date Tue, 05 Jun 2007 02:17:47 GMT
On 6/4/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Mikhail Loenko wrote:
> > it has been a while since we made our first milestone...
> >
> > Since that we have already fixed 250+ issues and we are continuing
> > doing good job :)
> >
> > Let's plan the next release. We had some discussion on desired frequency
> > of the milestones and I saw opinions 1 month, 2 months, 1 quarter. So
> that
> > 2mo seems to be an average.
> I like 2 months, it is a good balance between giving people time to get
> interesting pieces of functionality in, while also ensuring we don't get
> too far off track wrt stability and shipping something.  From a consumer
> pov, having a new stable build every two months also sounds about right.
> > If we go with 2mo interval, than M2 should be somewhere
> > at the end of June. I suggest that we agree on some date and then
> > agree what should be our focus for M2.
> >
> > After that we review current bugs and mark those that we want to fix
> > by the milestone.
> Sure.  I volunteer to create some targets in JIRA if people want to
> track issues explicitly that way.
> > My opinion wrt the focus is we should continue improving stability
> > as measured by ability to run real apps. And we probably should fight
> > against crashes as the most annoying type of failures.
> >
> > opinions?
> Fixing bugs and stability is always a good goal.  Beyond that we should
> aim to complete more of the Java 6 work, merge in some of the bulk
> contributions, enable more excluded tests, and set ourselves some
> completeness and performance goals (even if that is just 'no
> regressions').
> Once we agree on the timescale we can be explicit about the goals.

The above is fine with me.  We can do the threading design/development work
in a branch.  Its tight but I think we can do the first bullet (Thread Block
Lifecycle) of the April 2 posting, "[drlvm]threading] a list of
design/development issues".  If we run out of time we can hold the branch
for two months and catch the next cycle.

> Tim

Weldon Washburn

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