On Tue, Oct 30, 2012 at 11:17 AM, 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. >
It may be worth reviewing this section on "test packages" versus "releases": http://www.apache.org/dev/release.html#release-types It is possible to have something less than a release. We do that, for example, with snapshots and release candidates. We could do something similar with a language pack as well. But it would need to be an "internal only" distribution, meaning we do not advertise it with the user community. It is just for internal testing. But if we want to have something available for the public at large to use, even if we indicate it is "beta" quality, then that is still a release. Specific example: We have 3 or so people helping with the Danish translation on the L10N list. If we make a snapshot build for them, full install or language pack, and advertise it only on that list and ooo-dev, then I don't think that is a problem. But we should not make any user-facing announcements, or website changes to point the public to the new language pack, until it is an official release. However, if we want to have a "beta release" of these lang packs, then this is not hard either: 1) Checked the PO files into the 3.4.x branch 2) Verify that they have correct license headers (assuming PO files allow a license header) 3) Generate a source package as a diff file of the branch against the 3.4.1 revision 4) Generate the binary packages, perhaps just lang packs, perhaps full installs 5) Sign the source package and binary packages 6) 72 hour release vote 7) Announce via blog, etc. The point we need to respect is that the "Apache" brand is associated with open source software that meets the expectations of license review that Apache promotes. So if something is broadly made available, we really should take it through the license review and voting process, and have a source release, even in small cases like this. Of course, this all has overhead, especially for you, the release manager. So we don't want to repeat this too frequently. But translators continue to come in, and will do so. It might help if we Adopt a convention that sets expectations clearly for project participants and users, maybe something like: 1) When a point release is necessary, for example to fix a critical bug, we will include any new additional languages since the last release, provided the translations are complete and will be tested before the Release Candidate is ready to be voted on. 2) If no point release is necessary, we will include new translations in the next major release. 3) However, if the next major release is more than X months away then we will release language packs for new translations that are complete and tested. I don't know what the value of X is for #3, but the idea is we probably don't want to do a lang pack immediately before a new release. We'd just roll it into the next release. Just an idea. Regards, -Rob > Juergen > > >> >> -Rob >> >> >>> Regards >>> Ricardo >>> >>> >>> >>> >>>> >>>> >>>> >>>>> >>>>> -Rob >>>>> >>>>>> -Rob >>>>>> >>>>>>> Regards, >>>>>>> Dave >>>> >>>> >
