|
What
is the policy on UI changes? Will they be permitted, with lead
approval, between Nov 30 - Dec 6?
As I
understood it, we were going to allow some UI changes (preceeded by a courtesy
note to the wtp-dev list) only until RC1. However, several devs are
skeptical that we can/should declare UI freeze tomorrow, and would like until
RC2. (Of course, that leaves little time to test those changes if we ship
a week later.)
Thanks, Ted
We’re scheduled to
produce our first WTP 1.0 release candidate, RC1, tomorrow (Wed) November
30th. As a reminder, the development process changes after
that:
- November 30 –
December 6: All checkins require Bugzilla
entry and component lead approval (recorded in CVS and Bugzilla). Only high
priority / high severity issues should be addressed. No API changes are
permitted (except to not declare as API anything with insufficient
documentation or testing).
- December
7th: RC2
produced.
- December 7 –
ship: Checkins require the process
above plus PMC approval and announcement on this email list once approved.
Each checkin will be assigned an RC; the PMC will schedule additional RCs as
needed. To propose a fix in this time period:
- Ensure that a Bugzilla entry
exists and that the relevant component lead will sponsor the request, and
provide all of the following in the writeup
- Benefit – who needs the fix
and why?
- Available workarounds (and
their suitability) – what happens if the fix is not included in WTP
1.0?
- Ideally the patch should be
available, but if not, then a concrete cost estimate to prepare the
fix
- Risk analysis (to stability
and performance) if the checkin is permitted
- Have the component lead send
the request to wtp-pmc@xxxxxxxxxxx.
Note that test and
documentation changes may continue beyond RC2, and are not subject to the
checkin rules above.
Due to the need for a
sufficient test window beyond the final RC, any extension beyond 12/9 will
result in a delay to the public release date (12/16) on a 1-for-1
basis.
|
