Re: R-T doesn't care about i18n? (was: Problem with committing to gnome-screensaver)

On 2/12/09, Luca Ferretti <elle uca libero it> wrote:
> Il giorno mer, 11/02/2009 alle 09.44 -0500, William Jon McCann ha
>  scritto:
>  > When we move to git immediately after 2.26.0 I trust that everyone
>  > will be informed and ready to tackle the workflow changes that result.
>  >  I suggest that instead of continuing this conversation we focus on
>  > making sure we're ready.
> William, sorry if this could appear a blackmail, but IMHO this plan of
>  you is very un-polite for all GNOME community, so I think if you will
>  move gnome-screensaver to git *before* the DVCS decision (if I'm right
>  by now git is only an option, not the final choice) I'll ask to remove
>  it from the list of GNOME Desktop modules.
>  In the past years we have hard worked in order to have *all* *official*
>  GNOME Desktop & Platform modules stored on the same repository (see for
>  example mousetweaks or hamster-applet), not only for translators' sake,
>  but for entire GNOME community.
>  Do you like git? OK, *by now* it's a *your* choice, not a *community*
>  choice. Start to develop on a separate, private git tree and frequently
>  update the official module on svn, like the empathy team is currently
>  doing.
>  Respectfully[1] , Luca.
>  [1] but little shocked for recent "I'm myself and I don't care about
>  GNOME community rules" events :(

Reading up on this heated thread, here's my take on it.

There are some non-arguable fundamental facts about any free software
development. One of the most fundamental facts is this:
  1) The maintainer of a project/module may do whatever he likes with it.

However, there have always been some fundamental requirements we (the
GNOME Translation Project) have required from modules officially
included in GNOME. I don't know if they have been encarved into stone
or sent out into space yet, but anyone who has ever followed GNOME
release engineering and new module discussions closely, should be
familiar with them. Some of the requirements include:

  2) Translators with an account should have access to all modules
officially part of GNOME.
  3) All modules officially part of GNOME should be kept in *the same*
GNOME repository.

That last one is equally important. GNOME translators translate
several hundreds of modules, and many translators need quick access to
many, many of those modules on a daily basis in order to update
translations. Using and remembering different workflows for each and
every one of the modules would be a nightmare, so we require the
workflow be the same for each module (with some extremely few
exceptions for directory layout in some exceptional modules).

But the "one repository" requirement has always been the same. The
"one repository to rule them all" used to be, now it is, and maybe in the not too distant future it will be However, the change to a would require a
Release Team decision on which DVCS GNOME should use, and a planned
cutover date for the *whole* repository.

The planned cutover date is because we would need to communicate the
change, and carefully update all scripts and documentation, in time
for the cutover date. *All* modules would need to be migrated at the
same date, otherwise we have a script/documentation nightmare. Of
course most of this situation is the same for the GNOME Documentation

So until the Release Team has decided on a DVCS for *all* of GNOME,
and has announced a planned cutover date, and the cutover has
happened, *no* core GNOME module should be removed from, or closed for
commits, on If a module maintainer wants to use a
different repo in the mean time, fine, but then a requirement would be
that they automatically sync *all* the changes in the module both back
and forward with in the mean time. Unless you can
reliably do all that synchronization automatically, you are *not*
allowed to move.

I have all the respect for module maintainers and their freedom to do
whatever they like with their module. But at the same time, being
"part of GNOME" is a stamp of approval of which there follows some
real hard requirements, both in terms of software but also in release
engineering and version control.

So, if some core GNOME module "jumps the gun" and switches to a
repository other than before the date of the Release
Team mandated big project-wide repository cutover for all of GNOME, I
would formally request of the Release Team to immediately *remove*
that module/project from the list of software included in GNOME.

This is of course all speaking with my formal "GNOME Translation
Project Spokesperson" hat on.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]