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 13:54:28 GMT
Ok, I thought "team" meant language teams. But I have searched the Wiki and
cannot find any documentation on the required QA procedure relating to
national languages.

Can it be, that it was never really defined and written down ??

For code, there seems to be guidelines, but also no real definition of how
much test need to be done (it is pretty well defined what happens when QA
finds a problem in a release candidate).

For the future, not for the set of languages, it would be a good idea to
have a clear definition of
- which QA gates has to be passed
- who (roles) defines  if a gate if full filled (national team, someone
else?)


Jan.



On 31 October 2012 14:42, Jürgen Schmidt <jogischmidt@gmail.com> wrote:

> On 10/31/12 12:18 PM, jan iversen wrote:
> > I do not understand the release discussion assuming juergen  is right.
>
> or I have misunderstand your question ;-) I think we as AOO can define
> how we do QQ and how we want to ensure the quality of our releases.
> Besides the functional aspects here we have to follow some Apache rules
> how releases have to be made.
>
> Juergen
>
>  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