| AW: [cdt-dev] End Game Update |
|
+1 from a European contingent member
:-)
Norbert Von: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Doug Schaefer Gesendet: Montag, 8. Mai 2006 16:52 An: CDT General developers list. Betreff: RE: [cdt-dev] End Game Update I know Chris mentioned
that he’ll be in transition and might have difficulty finishing his work by the
end of May. >From the PDOM perspective, since I’m using heuristic based
solutions to make the indexing faster, the more time I can spend tightening
those heuristics, the better quality indexing we’ll get. And we do have 950 bugs
in bugzilla, although not all of them need to be fixed in
3.1. But then, we do need
some time to soak the CDT before release and two weeks might not be enough for
that. How about the following, then: RC0 – May 1
(done) RC1 – May
15 RC2 – May 29 (end of
free-for-all bug fixing) RC3 – June 12 (critical
fixes only, GA candidate) RC4 – June 26 (if
necessary, emergency fixes only) So, after May 29, all
bugs that are fixed should be published to the cdt-dev list. Making them more
public should help the committer decide whether the fix is really critical or
not. The goal is zero fixes after June 12. Any bugs that we want to fix then
should be published to the list before the fix is committed so we can input from
the group. Better/worse? We can
wait until tomorrow to decide to ensure we can get feedback from our European
contingent. Of course, any policy we set can only be enforced if everyone agrees
to it. Please speak up J. Doug Schaefer, QNX
Software Systems Eclipse CDT Project
Lead, Tools PMC member From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Treggiari, Leo I don’t need the extra
time – other than for documentation. I think it would be good to get an
idea on who needs the extra time to fix problems that they are already aware of.
Naturally, new problems will be reported as we continue testing the
RCs. Thanks, Leo From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Doug Schaefer After considering feedback from the
conference call and looking at my own schedule, I’d like to propose the
following changes to the 3.1 end game. I have to admit that picking the end of
May for RC1 and making it the provisional last RC was somewhat arbitrary. I
think the number of contributors to 3.1 is small enough that we can manage the
end a bit tighter. As such, here’s another
proposal. RC0 – May 1
(done) RC1 – May
15 RC2 – May
29 RC3 – June 12 (GA
candidate) RC4 – June 26 (only if necessary,
emergency fixes only) This will give us more formal
bi-weekly releases to the community for testing. It also pushes the GA candidate
out to June 12 and still gives us two weeks to ensure there are no more fixes
needed. Please comment. Does this push the
envelope too far? Is this a more realistic
schedule? Doug Schaefer, QNX Software
Systems Eclipse CDT Project Lead, Tools PMC
member |