On 5 August 2013 21:55, Rob Weir <robw...@apache.org> wrote: > On Mon, Aug 5, 2013 at 3:30 PM, Marcus (OOo) <marcus.m...@wtnet.de> wrote: > > Am 08/05/2013 08:16 PM, schrieb Rob Weir: > > > >> It looks like some regressions slipped through into AOO 4.0.0, and I'd > >> hate to wait until 4.1 to see them fixed. So I wonder if we can aim > >> for a 4.0.1 release in the next few weeks to address the specific > >> high-urgency issues? We could also use this opportunity to roll in > >> whatever new translations are available. > >> > >> Suggested parameters of the release: > >> > >> 1) No string changes. So existing translations don't need to change, > >> unless they are correcting a translation defect. > >> > >> 2) We carefully screen the code changes that are made. A fast > >> turnaround release depends on not introducing any new bugs. If we can > >> control carefully the changes going in then we can avoid spending a > >> month to re-test. We'd focus the test effort on the fixes made, and > >> related areas. > >> > >> 3) Use the "release blocker" flag to propose defects for inclusion in > >> the 4.0.1 release. > > > > > > +1 to the 3 above. > > > > > >> 4) New translations are rolled in, since a new translation cannot > >> break core code. > > > > > > That's not automatically correct. Please remember the Calc issue were > > functions names had the same name (was it in Italian?) even when they had > > different purposes. The result were unusable spreadsheets. > > > > > I think of it this way: Adding a new translation cannot break other > translations. It can only break itself. So adding translations has a > localized impact in terms of testing. >
I agree with rob, its only a theory that one translation can break another. > > > So, in general yes but it is not 100% save. > > > > > >> 5) The one "feature" that I'd consider rolling in would be changes to > >> work with Mac OS 10.9. It is not a regression in our code per se, but > >> it is a new issue, and a critical one. > > > > > > I don't follow Mac issues closely but I'm sure there is already a BZ > issue. > > > > > >> 6) Obviously, all bug fixes get checked into trunk as well, so they > >> are included in 4.1. > > > > > > Ahm, yes, obviously. > > > > > >> 7) Aim to have 4.0.1 ready for September X, where 0<X<31 The earlier > >> the better, IMHO. > > > > > > I wouldn't set a (more or less) fixed date. In any case we should make > sure > > that all the issue candidates are considered. > > > > As in most cases it will come down to the question: Do we hold back > on fixes we've already made because there are other fixes that we have > not yet made? So I'd start out with a goal date that we can all aim > for. That helps coordinate the effort. But we all know that dates are > not carved in marble. > When I consider what I hear in the "real" world, I would prefer a fast release, solving the most important issues. We always have the possibility to make a 4.02 if really needed. rgds jan I. > > -Rob > > > Marcus > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
