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? Thanks, Mikhail 2007/6/5, Weldon Washburn <[EMAIL PROTECTED]>:
On 6/4/07, Tim Ellison <[EMAIL PROTECTED]> 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
