I do not understand the release discussion assuming juergen is right. why don't we ask each team to send a mail confirming they have made QA then we would release the language packs officially (at least this time)
this would also give us time to discuss the ideal situation. juergen: you will (hopefully) soon get an extra pair of hands to help! Den 31/10/2012 11.10 skrev "Jürgen Schmidt" <jogischm...@gmail.com>: > On 10/30/12 4:22 PM, jan iversen wrote: > > Question: Is there a rule in "the apache way" defining who can do QA, or > is > > it totally up to the single teams ? > > It's up to the teams I think > > > > > Do we use the "review statistic" in pootle to anything, it seems actually > > quite clever. > > we don't make use of it right now and I have to confess that I haven't > really looked in it yet because of the lack of time. > > > Juergen > > > > > Jan. > > > > On 30 October 2012 16:17, Jürgen Schmidt <jogischm...@gmail.com> wrote: > > > >> On 10/30/12 2:46 PM, Rob Weir wrote: > >>> On Oct 30, 2012, at 9:03 AM, RGB ES <rgb.m...@gmail.com> wrote: > >>> > >>>> 2012/10/30 Jürgen Schmidt <jogischm...@gmail.com> > >>>> > >>>>> On 10/27/12 3:57 AM, Rob Weir wrote: > >>>>>> On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir <robw...@apache.org> > wrote: > >>>>>>> On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher < > dave2w...@comcast.net> > >>>>> wrote: > >>>>>>>> > >>>>>>>> On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote: > >>>>>>>>> ... it would probably allow to skip the release process and > >> voting, > >>>>> since we would merely be adding 3-5 binary artifacts (built for > >> different > >>>>> platforms). > >>>>>>>> > >>>>>>>> It is an interesting question if we should only vote for source > >>>>> releases. Certainly these are the only "official" release. I think > >> that the > >>>>> practice is to vote for binary packages as well. Clearly those have a > >>>>> different bar. It is worth discussing, but I am inclined to think > that > >> we > >>>>> do need to VOTE on these packages, but in this case we are voting at > a > >>>>> certain level of trust for the packager and translations. > >>>>>>> > >>>>>>> But the point is we need to release the source that the binaries > >>>>>>> depend on, where that source is from this project. > >>>>>>> > >>>>>>> It would be one thing if we were just releasing a new platform port > >> of > >>>>>>> existing source packages. But we're not. > >>>>>>> > >>>>>>> We're talking about new translations resources, where such > resources > >>>>>>> are in SVN and are required as part of the build process in order > to > >>>>>>> build the localized binaries. No downstream consumer of the source > >>>>>>> will be able to build these localizations without having access to > >> the > >>>>>>> translated resources. Therefore these resources should be > reviewed, > >>>>>>> voted on and released. > >>>>>>> > >>>>>>> Remember, the translations are non-trivial creative works, > >>>>>>> translations of not only UI strings, but larger text passages from > >> the > >>>>>>> help files. They are under copyright and made available under > >>>>>>> license. So we need to do our due diligence via the release > process > >>>>>>> before we distribute such materials. > >>>>>> > >>>>>> Should say, "before we distribute such materials in source OR source > >>>>>> and binary form". The issues are the same. > >>>>>> > >>>>>> Remember, the source package is canonical. I'm surprised to hear > talk > >>>>>> now of releasing only binaries. > >>>>> > >>>>> > >>>>> > >>>>> I am still not sure how we can address this but I would really like > to > >>>>> make new translations available as soon as possible. > >>>>> > >>>>> What about the idea to prepare official developer language packs > based > >>>>> on the AOO34 branch and where the new translations are already > checked > >>>>> in? If we decided later to release a 3.4.2 because of other critical > >>>>> security or general bugfixes the new translations becomes included > >>>>> automatically. > >>>>> > >>>>> The new language packs will have the same version number 3.4.1 but > are > >>>>> not officially released and are available via the snapshot page. > >>>>> > >>>>> When we reach a state where we have "release" build bots, we can > >>>>> probably trigger much easier a complete respin with the same product > >>>>> version but based on a new revision number including the new > >> translations. > >>>>> > >>>>> Juergen > >>>> > >>>> +1. I like the idea. We can put on the download page a link to > >> "additional > >>>> untested language packs" and add "these language packs are being > >> prepared > >>>> for the next AOO version, but you can use them right now" or something > >> like > >>>> that. > >>>> > >>> > >>> Even beta releases are still releases from the Apache perspective and > >>> still require that we go through a release vote. > >>> > >>> Why are we trying so hard to avoid this process? It isn't that hard. > >>> And it is important that we follow the procedures before putting the > >>> "Apache" label on software we make available to the public. > >> > >> I don't see that we try to avoid this process. But with with a certain > >> level of QA we have to test the new language builds anyway. > >> > >> Means in detail we can start with the snapshot builds and can test it. > >> If we get no complains we can create a new src release (a respin if > >> possible) where the new translations are included. And we upload only > >> the new src release and the new language packs. I would be also fine > >> with uploading full install sets but this is matter of taste and space. > >> > >> Juergen > >> > >> > >>> > >>> -Rob > >>> > >>> > >>>> Regards > >>>> Ricardo > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> -Rob > >>>>>> > >>>>>>> -Rob > >>>>>>> > >>>>>>>> Regards, > >>>>>>>> Dave > >>>>> > >>>>> > >> > >> > > > >
