Re: Moduleset Reorganization -- Take two

[Kenneth Nielsen <k nielsen81 gmail com>]

2010/10/12 Sandy Armstrong <sanfordarmstrong gmail com>:
> On Tue, Oct 12, 2010 at 1:31 PM, Murray Cumming <murrayc murrayc com> wrote:
>> On Tue, 2010-10-12 at 15:03 +0200, Vincent Untz wrote:
>>>
>>> Good point. It's fair to expect projects not using the GNOME
>>> development
>>> cycle to publish a schedule with freezes.
>>
>> You would allow modules in the module sets that don't follow the GNOME
>> schedule? Then it loses all meaning. Once again, the purpose of the
>> release schedule (of which the module sets are just a part) is to
>> release software.
>
> I agree here.  I'm not sure how the i18n and docs teams are supposed
> to do their jobs if they have to track dozens of different schedules.
>
> Maybe those teams should only devote resources to an application on
> the occasion that a release matches up with the GNOME schedule?  This
> would allow for apps to have more or less frequent releases, but at
> the same time encourage them to have their releases match up with the
> GNOME schedule whenever possible.

I would very much like to give a translators point of view here. I
think that reorganising the module sets in some way is a good idea,
because right now the current situation has us (translators) unfairly
favouritising certain apps because they are part of the dekstop module
set.

The main thing that I care about, is to provide quality translations
of GNOME related software (prioritised on some way after importance
and popularity) to users, therefore the present situation where
rhythmbox gets a lot more translations love than banshee (because one
is part of the grand desktop module set and the other is lumped in
with all the others in Extra applications) is far from optimal. I
would like to see this resolved in some way.

The problem here is off course that some compromises will have to be
made. I would like to have all the popular apps gathered somewhere so
we know what to focus on, I would also like them to all release
following the GNOME schedule, but on the other hand I know that
certain popular projects would rather stay out of such a grouping than
to conform with our schedule, so something has to give.

If I give it my best at being a little frexible, I think we can make
it work from a l10n point of view. The key is information and
overviews. I think not everybody understands just exactly how
important damned lies like functionality is to us translators and how
much we use it. The reason is that we usually touch a lot more modules
than any other contributor group. We frequently browse through lists
to find work and access progress. So if... the Apps module set will
have its own page in damned lies and if... string freeze and release
dates are present there on that overview list, for the apps that don't
follow the GNOME release schedule, and if.... the number of those apps
are kept low, then I think that is still a workable solution.

Regards Kenneth