Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Closure process for CDT M7

cdt-dev-bounces@xxxxxxxxxxx wrote on 04/26/2005 02:40:16 PM:

> Hi Dave,
> 
> > Note that the current plan on the web has M7 scheduled for May 30.
> 
> Yes, but I thought that we agreed at April's meeting to slip that
> date (and all following dates) by two weeks.  Actually, it may not 
> have been *exactly* two weeks, it was defined to be the Eclipse M7 
> date + n (which "n" I didn't record but was about a 2 week slip).

Yes, It should be Eclipse M7 + 4 weeks. Given the changes we've seen in 
the recent integration builds, the 4 weeks will be needed...

Anyway, Derrick has clarified in a very recent note.

> > As a starting list, I propose: 
> >       1.  Clean up the defects in bugzilla on 3.0: 
> >               a.  No open enhancement requests 
> >               b.  No defects assigned to an inbox owner 
> >               c.  All other defects triaged so that the only open 
> >                   defects are ones that we intend to fix before GA. 
> >                   (this way anybody who has a defect moved off of 3.0 
> >                    can speak up while there is still time to affect 
> >                    the contents of 3.0)
> 
> I don't know what an "open" bugzilla is.  I'm guessing that you may 
mean:
>   Status == (NEW | ASSIGNED | REOPENED) && Target == (3.0* || undefined)

I treat undefined, i.e. '--', as equivalent to future. The owner commits 
to fixing it in 3.0 by changing the target to 3.0*, or explicitly commits 
to not fix it by changing it to Future. There are no implicit commitments 
to do work in this game :)

Doug



Back to the top