Hi Jörg, IMHO this is already covered by > A release relevant issue may be deferred to the next release if effort > or risk estimation doesn't allow a fix in a reasonable time frame and > has been qualified no to be a release_blocker. but maybe you're right and we need to be more specific,
Martin On 01/19/2011 01:42 PM, Jörg Jahnke wrote: > Hi Martin, > > 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" > ... > > Regards, > > Jörg > > > Am 19.01.2011 12:19, schrieb Martin Hollmichel: >> Hi, >> >> let me suggest some changes for the release of 3.4, please see >> http://blogs.sun.com/ratte/entry/some_changes_for_the_openoffice for the >> changes and the reasons why. >> >> 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 >> automatically >> * 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. >> >> feedback by the participants of the release status meeting is >> appreciated, especially we need an agreement of how to update e.g. >> following pages: >> http://qa.openoffice.org/issue_handling/bug_writing_guidelines.html >> http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority >> http://wiki.services.openoffice.org/wiki/Showstopper >> http://wiki.services.openoffice.org/wiki/Release_criteria >> http://wiki.services.openoffice.org/wiki/OOoRelease34 >> >> thank you for your support, >> >> Martin >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
