incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <jancasacon...@gmail.com>
Subject Re: [RELEASE] Releasing new languages for 3.4.1
Date Wed, 31 Oct 2012 11:18:15 GMT
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" <jogischmidt@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message