Also, I hope that 1.0 will be both more
stable heading into rampdown and have more testing resources devoted to it from
all the participating member companies than was the case with 0.7. Both should
help reduce the risk of last minute show-stopping bugs and the commensurate
need for additional RCs. Let’s focus attention on QA and solid I-builds throughout
the entire 1.0 dev cycle to help make that the case.
From:
wtp-pmc-bounces@xxxxxxxxxxx [mailto:wtp-pmc-bounces@xxxxxxxxxxx] On Behalf Of Lawrence Mandel
Sent: Friday, July 29, 2005 5:50
PM
To: WTP PMC communications
(including coordination, announcements, and Group discussions)
Subject: Re: [wtp-pmc] Proposal
for Shutting Down Future Releases
Arthur,
As
far as I understood the process this is how things should have worked for 0.7.
RC1 was supposed to require component owner approval, RC2 was supposed to
require approval from a PMC member, and post RC2 was supposed to require
approval of the whole PMC (as it, for the most part, did).I think the problem
was with enforcement of the policy rather than with the policy itself and the
policy timelines work as you suggest they should. RC2 was very open for bug
fixing allowing for a lot of fluctuation in the code and the introduction of
new problems as many people rushed to fix bugs. I suggest the shutdown process
be made clear to all WTP developers early on and that the process be enforced
and not relaxed during the 1.0 shutdown period. This will require the help of
the component leads.
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx
Arthur Ryman/Toronto/IBM@IBMCA
Sent
by: wtp-pmc-bounces@xxxxxxxxxxx
07/29/2005 09:01 AM
Please
respond to
"WTP PMC communications (including coordination, announcements, and
Group discussions)"
|
|
To
|
wtp-pmc@xxxxxxxxxxx
|
cc
|
|
Subject
|
[wtp-pmc] Proposal for Shutting Down Future
Releases
|
|
It's great that we made our date with WTP 0.7, but we are shipping freshly
built code that may have problems that were introduced at the last minute. I'd
therefore like to propose a policy for future releases.
I suggest that we allow a minimum of 1 week to elapse between the time we build
our final release candidate and the time we declare it. This means that we
automatically add 7 days to the date of the build before we officially release
it. Furthermore, we do not rebuild it just to create the final version. We
actually ship the 7-day old version, so it should be created with the final
file names, etc. (No RC1, etc. in the names).
During the 7 day period, we test the code and create a list of serious known problems.
If we decide that this list is too long or bad, we fix the errors and reset the
clock.
The benefit of this process is that we ship something with known quality. I
believe it is better to do that than ship something with last minute changes,
and hope for the best.
Arthur Ryman,
Rational Desktop Tools Development
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet: http://labweb.torolab.ibm.com/DRY6/_______________________________________________
wtp-pmc mailing list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc