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. > 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. -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
