On Tue, Aug 6, 2013 at 9:37 AM, Jürgen Schmidt <jogischm...@gmail.com> wrote: > On 8/6/13 3:05 PM, Andrea Pescetti wrote: >> Rob Weir wrote: >>> a 4.0.1 release in the next few weeks to address the specific >>> high-urgency issues? [...] >> >> Good plan. I'm adding some remarks below, to see the release not only >> from the users point of view, but from the community perspective too. >> >>> 3) Use the "release blocker" flag to propose defects for inclusion in >>> the 4.0.1 release. >> >> OK, but by default the "proposed 4.0.1 release blocker" flag (when it >> exists) should be set for: >> 1) All the issues with keyword "regression" found after 4.0 was released >> 2) All the issues nominated as release blockers for 4.0 and unresolved. >> >> It is important that we don't fall in the "release and forget" trap, >> i.e., "this bug was already known when 4.0 was released, so it doesn't >> need to be evaluated again for 4.0.1". At least, we should re-evaluate >> the old proposed blockers: some of them might have become more relevant. > > in theory and with an idealistic view I would agree but for practical > reason I don't. You should not forget that issues have to be fixed as well. > > We should really be careful here and should focus on the most serious > issues only. From my point of view many proposed showstoppers for 4.0 > were no showstopper and why should we prioritize them now. > > And even regressions have to be analyzed where the root cause comes from. > > >> >>> 4) New translations are rolled in, since a new translation cannot >>> break core code. [...] >> >> Here (and, by the way, the infamous problem for Italian was a broken >> translation of style names a few years ago; indeed, this kind of >> problems does not affect other translations) it is really important that >> we are able to clearly communicate to volunteers that they can target >> 4.0.1. >> >> This is not the case at the moment: we have volunteers who are ready to >> work and Pootle is not ready yet for their language, or it only offers >> 3.4.1. See http://markmail.org/message/4oxacrviktdbmbcv for more. > > where are the issues? Where are the volunteers to work on this? Nobody > should plan with other peoples time and willingness >
So maybe mark things in BZ as regressions, etc. But only set the Release Blocker Request flag when a fix is actually available? That might make the most sense for a workflow. We can then continue to use BZ severity field and regression keyword to categorize the issues that don't have fixes yet. -Rob >> >> The opportunity is now and we should definitely make it a priority for >> 4.0.1, so we can tell volunteers that 4.0.1 can be released in their >> language and that they can start contributing immediately. This has the >> potential to motivate contributors. > > I agree in general but there is a limitation as you know > >> >>> 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. [...] >> >> A minor and low-risk "feature" is updating bundled dictionaries. As I >> explained in a mail to this list, the update behavior is not optimal >> from a usability point of view so it's best to update dictionaries just >> before the new release. Needless to say, I'd volunteer for that. > > +1, it seems to fix a problem that is really annoying > > Juergen > >> >> Regards, >> Andrea. >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
