harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [general] Harmony M2 schedule
Date Tue, 05 Jun 2007 03:55:12 GMT
Let's have end of month (June, 30?) as a release date. Now we need to
define a date for code freeze (when only critical bugs are fixed) and
define how we will commit between code freeze and release (each commit
approved by one more committer?)

I think the code freeze date should depend on the longest test cycle
we have (I've seen somewhere about 48-hour scenarios?) and be ~2-3
cycles (1 week?) prior the release.

We also need a feature freeze date (1-2 weeks prior code freeze?) when
no major changes or redesigns are allowed.

And we need to set up requirements for the release. We already see a
good wish-list here. The only concern I have is that its focus is
almost everything: stability, performance, and completeness. Though I
completely agree with each of these directions, I have a feeling that
having everything in focus means not having a focus.

So I propose that we go this way: we have directions, we already
discussed them many times. Now let's create requirements based on the
list of directions: *each person who adds something to requirements is
committing to and will be responsible for meeting that requirement*

The requirements could be to have something specific in stability,
have something specific in performance, completeness, java6, etc

Once we compose a list, say 1..N of requirements, we create keys or
tags for JIRA, say M2-REQ1, ..., M2-REQN and mark bugs affecting
requirements with these key words. So each person would easily find
bugs affecting requirements he is responsible for.

Comments? Requirement proposals?


2007/6/5, Weldon Washburn <weldonwjw@gmail.com>:
> 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.
> Regards,
> > Tim
> >
> --
> Weldon Washburn

View raw message