incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [RELEASE] Releasing new languages for 3.4.1
Date Tue, 30 Oct 2012 15:53:28 GMT
On Tue, Oct 30, 2012 at 11:22 AM, jan iversen <jancasacondor@gmail.com> wrote:
> Question: Is there a rule in "the apache way" defining who can do QA, or is
> it totally up to the single teams ?
>

>From an organizational perspective Apache is mainly interested in the
health of its communities and in the certain IP-related qualities of
its releases.  So you won't see an ASF-wide mandate for unit testing,
or how code coverage should be measured, etc.  These details are left
to the project communities to decide.  Quality issues, in some sense,
take care of themselves in a Darwinian sense.  If a project has poor
quality and does so consistently, it will cease to exist, since
attracting volunteers becomes difficult.

As for "who" can do QA, we welcome all volunteers interesting in
helping here.  We have a separate list, ooo-qa@incubator.apache.org
dedicated to this topic.

> Do we use the "review statistic" in pootle to anything, it seems actually
> quite clever.
>

I don't know.

-Rob


> Jan.
>
> On 30 October 2012 16:17, Jürgen Schmidt <jogischmidt@gmail.com> wrote:
>
>> On 10/30/12 2:46 PM, Rob Weir wrote:
>> > On Oct 30, 2012, at 9:03 AM, RGB ES <rgb.mldc@gmail.com> wrote:
>> >
>> >> 2012/10/30 Jürgen Schmidt <jogischmidt@gmail.com>
>> >>
>> >>> On 10/27/12 3:57 AM, Rob Weir wrote:
>> >>>> On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir <robweir@apache.org>
wrote:
>> >>>>> On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher <dave2wave@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
>> >>>
>> >>>
>>
>>

Mime
View raw message