| 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 |