| RE: [cdt-dev] End Game Update |
|
+1
___________________________________________
Chris Recoskie Software Designer Texas Instruments, Toronto http://eclipse.org/cdt
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Doug Schaefer
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
|