Am 09/12/2011 06:08 PM, schrieb Rob Weir:
On Mon, Sep 12, 2011 at 11:38 AM, Joe Schaefer<[email protected]> wrote:
----- Original Message -----
From: Donald Whytock<[email protected]>
To: [email protected]
Cc:
Sent: Monday, September 12, 2011 11:07 AM
Subject: Re: Umbrella projects
On Mon, Sep 12, 2011 at 10:42 AM, Rob Weir<[email protected]> wrote:
Why not just send the ballot to
ooo-commits in Sumerian?
I should think that would have to at least start out on ooo-dev-sux.
NL development outsider here, asking for clarification...Would changes
to the ixn components be considered changes to the "source"? Because
if it doesn't involve actual code changes I could see such a thing
justifying a vote on some ooo-dev-xx but then only needing lazy
consensus on ooo-dev.
90% of the organizational concern for releases regards their licensing,
which I don't believe gets translated into other languages (at least not
without legal-discuss@ approval of the actual text.)
I have no idea where ixn lives in the subversion tree, but mods that
are committed to the tree are still mods that need to be voted on
when it comes time to release something based on those files.
My suggestion is for per-lang committers to be placed on the PPMC,
and for those folks to conduct their votes on their per-lang list.
Once that's accomplished, lets leave the training wheels on at first
and ask ooo-dev@ to approve the release candidates via lazy consensus.
Then take the whole shebang to the general@incubator list for formal
approval by the IPMC (this step will go away when ooo graduates).
Maybe someone can clear up exactly what we're talking about with a
language release.
My understanding was we have a core code base, that has all
code-dependent i10n features in it. We also have translations,
dictionaries, etc., per language. We can build a release in English
and then require that the user download an additional "language pack"
to enable an additional language. Or we can spin off a build (more of
a new install build) to include an additional language.
You can see this here, with the existing releases:
http://download.openoffice.org/other.html
So the question comes down to: what languages do we support via
officially-released install images, versus which ones are supported
via language packs? For example, today, for Uzbek, it is only
available via a language pack.
In the past we had an agreement that if a language is translated for 80%
or more (UI *and* help) then it's enough to make an own full install. If
not it was possible to build just a language pack.
But if the translation ratio was really too low then no localized build
was done as the very most strings would be in English but not in the
respective language.
The details are described here:
http://wiki.services.openoffice.org/wiki/Release_criteria
This might vary based on the timing of the translation. In other
words, we might release a new version with core languages supported,
and then enable additional languages over time as translations
complete. It would not make sense to wait for a release until all 160
language translations are complete.
It would be better to have a translation deadline. Otherwise you will
get new strings somewhen in the year and a request to make a build. When
we come back to 110 languages this would be an overhead that nobody want
to do.
In the past it was accepted that a NL community has to fulfill the
deadline (also because it was known many weeks up-front), otherwise they
had to wait for the next release.
I think it would be overkill to support this model via PPMC
delegation. OOo supports 110 languages. At 3 PPMC members per
language (for the required 3 +1's in a release vote) that comes to 330
PPMC members. Of course, there will be some overlap, so maybe it
comes down to 200 new PPMC members or so, plus or minus 50. I'm not
sure that makes sense.
So it is not clear that delegation to NL PPMC members really solves
the problem. We need to be having a conversation between those who
are doing the translations, those testing the translations and the
PPMC, on whether a translation is ready to release, either via
language pack or as a full install.
Of course, if the Mentors wish to mentor 110 different NL groups on
the finer points of release management at Apache, then I don't want to
get in their way.
But I'll propose a simpler solution. We should make it easy to
nominate and approve releases of language packs and full installs
based on already approved source releases. All we need is some
indication from an expert that a given translation was ready. This
might be from a PPMC member, a Committer, or a number of Users on the
user list who have tried a pre-release language pack snapshot. We
need to rely on expertise here, expertise outside of the PPMC. But
once we decide to spin a new release, I don't think why this is not
most easily done by a vote on ooo-dev. And I'd feel much better if
the same volunteers who are building the core installs also built the
110 language versions. It makes zero sense to have 330 different
people doing this (110 languages x 3 platforms). There is too much
scope for error.
-Rob
Right, providing any build should be a task for core development.
However, to test these builds should be a core task for the NL
communities. Because only the Japanese knows if the Japanese build is
good enough to release, right? ;-)
Marcus
