On 2/25/10, Charles-H. Schulz <charles-h.sch...@laposte.net> wrote: > > > Alexandro > (okay let's set our discussion on d...@native-lang and please, pay > attention when replying because of the inline comments...) > > > Le 25/02/10 12:23, Alexandro Colorado a écrit : > > > On 2/25/10, Charles-H. Schulz <charles-h.sch...@laposte.net> wrote: > >> > >> > >> Hi, > >> > >> Yes I did. I don't find it satisfactory, for three reasons. > >> > >> 1) as mh wrote on the issue as an answer to you, there was ample times > >> and several RCs where l10n specific issues were raised, so how come your > >> > >> issue(s) were not raised? > >> > >> How you know we didn't look at issue > >> http://www.openoffice.org/issues/show_bug.cgi?id=108563 > > > > That is something I don't know indeed, but then the remedy was clear; > bug(s) would be fixed in the 3.2.1 > > > > >> > >> 2) If the bugfix is scheduled for the 3.2.1 then wait for the 3.2.1. I'm > >> sure that there are other bugs, l10n specific or not, but there is also > >> > >> a release process and schedules, so please follow them. > >> > >> I dont think I need to wait. As QA release lead for ES, I would have not > >> approve a build with such issues, and would have probably wait for 3.2.1 > all > >> together skipping the 3.2 cycle. Fortunately this patches where accepted > on > >> Pavel's build so we release this. > > > > If you don't approve a build because of specific issues that's one thing > and you are entitled to it. If you switch builds right before the > release of a major version that's just not acceptable: either raise the > issue and inform the QA team and the L10N project or agree to follow the > QA and release processes, which means, wait for the 3.2.1 . And again, > there was several RCs in this case. > > > > >> > >> 3) Last but not least, we have a situation now where we have two sources > >> > >> for spanish builds. We have the vanilla one and the ones from Pavel. > >> > >> If what 108563 happens, and take the patches from Pootle then it > shouldnt > >> be any difference. > >> This calls for one selection of one source the need to stick to it. You > >> may, on the other hand have good reasons to distribute Pavel's builds, > >> but then please state your reasons so that at least there is no > >> > >> duplication of effort. In any case, it's about coherence. > >> > >> No is about responsiveness, if builders decide to drop our issues as > >> showstoppers and move to a different cycle, then we are also able to > move to > >> a different tree whenever we think this is trully a stopper for a > release. > > > Responsiveness is an easy argument, because then you will get questions > on the QA: I don't think users can stand changing versions based on > different builds on ever release so that's a coherence issue at the very > least. Responsiveness for the sake of responsiveness does not elude > responsibility and long term quality. > > However, the point that is raised, and please allow me to insist, is the > question of choosing one source and sticking to it. Perhaps it would be > worth to look at criteria where non vanilla builds are chosen, that > could at least clarify some questions. > > > Charles. > > > > > >> > >> Best, > >> Charles. > >> > >> Le 24/02/10 20:06, Alexandro Colorado a écrit : > >> > >>> Did you read my response in the bug? > >>> > >>> On Wed, Feb 24, 2010 at 10:58 AM, Charles-H. Schulz > >>> <charles-h.sch...@laposte.net> wrote: > >>> > >>> Hello Alexandro, all, > >>> > >>> It has come to my attention > >>> (http://qa.openoffice.org/issues/show_bug.cgi?id=109060 > >>> <http://qa.openoffice.org/issues/show_bug.cgi?id=109060>) that the > >> ES > >>> project is now proposing non vanilla builds (Pavel's builds) > instead > >> of > >>> the regular ones. I'm fine with Pavel's builds, but they are > usually > >>> not used when a vanilla version is available. > >>> > >>> Would you like to explain why the project chose this option? > >>> > >>> Thank you, > >>> Charles. > >>> > >>> > --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@native-lang.openoffice.org > >> > >>> <mailto:dev-unsubscr...@native-lang.openoffice.org> > >> > >>> For additional commands, e-mail: > dev-h...@native-lang.openoffice.org > >> > >>> <mailto:dev-h...@native-lang.openoffice.org> > >> > >>> > >>> > >>> > >>> > >>> -- > >>> Alexandro Colorado > >>> OpenOffice.org Español > >>> IM: j...@jabber.org > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@native-lang.openoffice.org > >> For additional commands, e-mail: dev-h...@native-lang.openoffice.org > >> > >> > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@native-lang.openoffice.org > For additional commands, e-mail: dev-h...@native-lang.openoffice.org > > Ok honestly I am not sure what is the big issue. 3.1 was also released under Pavel builds (#101415) and nobody really issue any flags. So 'switching' arrgument doesn't really apply here.
I also don't see the bigger issue whenever we used pavel's build or vanilla. Most of the previous QA requirements was only about providing an MD5 which we did for at least the mylinuxclasses.com windows build (since pavel don't provide them anymore). Most of the locale builds are also done in Pootle so there is really no fork or duplicate of efforts here, except maybe for a second build which didn't apply any updates to begin with. Ihi decision to wait until 3.2.1 as opposed to apply them right for RC5 would have been the best answer here. But we work too much too quickly to end up with no build for 3.2.0. -- Alexandro Colorado OpenOffice.org Español IM: j...@jabber.org