The changes in short form:
* define criteria release relevant issues, only these issues will get
3.4 target milestone
* remaining issue will get target milestone at the time of integration
* better transparency for issue by using <unassigned> ownership
* branch off for release will happen after stabilization phase
These changes will help to reduce the amount of rc's for the 3.4 release
and make the release more predictable, hopefully :-)
Affected by these changes are mainly QA and DEV people, setting keyword
or fixing bugs and of course the members of the release status meeting,
translation or documentation folks are not directly affected.
your proposal is definitely a step into the right direction IMHO.
Since in the past we've often had cases where a fix in one RC caused a
regression in the next one, I'd also like to see the developer's risk
estimation have an effect on whether an issue gets accepted as a
showstopper or not. Therefore I'd like to modify your proposed list of
showstopper criteria as follows:
* keyword data_loss set _and_ Prio is P2, P3 or P4 _and_ the developer's
risk estimation for breaking other functionality is "medium"
* keyword regression has been set _and_ Prio is P2 or P3 _and_ the
developer's risk estimation for breaking other functionality is "low"
* keyword usability or accessibility _and_ Prio 2 _and_ the developer's
risk estimation for breaking other functionality is "low"