| RE: [cdt-dev] End Game Update |
|
+1 from me. Sorry, we had a holyday
on Monday and Tuesday and I could not reply earlier.. Mikhail From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer Thank you all. There have
been no dissentions so far, so we can assume this is the plan of record. First step is RC1. The
candidate will be the morning build on Monday (build time is 1 a.m. EDT). All
active committers (i.e those who have actually committed something recently)
should give this build a whirl and give a go/no go. No go is a request for
rebuild. Once we have all the go’s I’ll publish the build as RC1. Let me know if this
doesn’t work for you. 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 +1 ___________________________________________ Chris Recoskie Software
Designer 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 |