On 01/19/11 13:58, Martin Hollmichel wrote:
On 01/19/2011 12:51 PM, Stephan Bergmann wrote:
On 01/19/11 12:19, Martin Hollmichel wrote:
* branch off for release will happen after stabilization phase
Stabilization phase might be an unlucky term here. I hope it is not
meant to imply that
On 01/20/2011 10:42 AM, Stephan Bergmann wrote:
On 01/19/11 13:58, Martin Hollmichel wrote:
On 01/19/2011 12:51 PM, Stephan Bergmann wrote:
On 01/19/11 12:19, Martin Hollmichel wrote:
* branch off for release will happen after stabilization phase
Stabilization phase might be an unlucky term
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
*
On 01/19/11 12:19, Martin Hollmichel wrote:
* branch off for release will happen after stabilization phase
Stabilization phase might be an unlucky term here. I hope it is not
meant to imply that there are phases where only select CWS (those
stabilizing the to-be-branched-off release) are
On 19.01.2011 12:19, Martin Hollmichel wrote:
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.
Hi,
how to handle a CWS with multiple issues? Some may pass the 3.4
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
On 01/19/2011 12:51 PM, Stephan Bergmann wrote:
On 01/19/11 12:19, Martin Hollmichel wrote:
* branch off for release will happen after stabilization phase
Stabilization phase might be an unlucky term here. I hope it is not
meant to imply that there are phases where only select CWS (those
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
