Re: Status page HEAD category?

[Christian Rose <menthos gnome org>]

ons 2004-04-14 klockan 19.31 skrev Gareth Owen:
> > To respond to your suggestion more specifically, I think a seperate HEAD
> > category of the translation status pages would be redundant for the most
> > part of the year, as it would overlap with the category for the latest
> > development release/next coming stable release anyway, as those modules
> > use HEAD during the largest period of development. And when they don't,
> > it's always at times where translators should indeed focus on the
> > branches for the latest stable releases.
> 
> This is certainly true for modules that following the gnome release
> cycle, but what about those that don't?  Since the status pages
> currently cycle inline with the gnome releases, they currently appear
> (at least to me) not track the non-gnome release very well.

This is certainly true, but IMHO it's very much an unavoidable side
effect of our resources being limited. Simultaneously tracking multiple
release cycles of other non-GNOME-core projects is indeed difficult, and
after all this is the GNOME Translation Project, so our first and
foremost priority should naturally be to track and translate the
software in the GNOME core (GNOME Desktop & Development Platform)
releases. Everything else is second priority.


> For example there presumably is a branch for supporting the stable
> evolution 1.4 release, but this isn't tracked by the status pages.

Hopefully this specific example will be solved in the future, as
Evolution will probably be proposed again for GNOME 2.8, and, if
accepted, hence follow the GNOME release cycles in the future.


> > At the same time we should remove the gnome-2-4 status pages, and the
> > gnome-2-6 status pages should be reduced to only monitor the
> > developer-libs and desktop sections, to spare some cpu cycles on Carlos'
> > translation status updating machine.
> 
> By reducing the gnome-2-6 pages to the core modules, doesn't this just
> mean we end up not tracking the translation status of the "stable"
> branches of everything else.

Basically yes, just as the situation is with the gnome-2-4 status pages
at the moment. However, for non-GNOME modules whose maintainers have
announced that it makes little sense for translators to translate HEAD
of their module for a while, we can still have a branch listed on the
gnome-2-8 extras pages, i.e. the gimp gimp-2-0 branch should probably be
listed instead of HEAD on the gnome-2-8 extras pages for a while, until
the maintainer announces otherwise.


> Which should initially at least still be a
> priority to translate over the development branches.  For example which
> version of gimp to we track the 2.0 branch which will still have minor
> releases or the HEAD branch for the next major release.

As the gimp maintainer essentially said that it made little sense to
translate gimp HEAD for a while, and that instead there will be more
stable releases coming from the gimp-2-0 branch, there's probably little
question on what gimp branch should be listed on the status pages.

However, for other non-core modules that branch off and where there's no
such announcement, only being able to list one branch on the status
pages probably means that HEAD should be prioritized and continue to be
listed. So yes, we don't currently have the resources to track all
branches of all non-core software, so we have to prioritize, and HEAD
wins unless there's a strong argument otherwise.


> Ideally, we should track both the stable (ie patch/minor release) and
> development branches of all the modules.  We could then look at this
> data from a number of different views, for example a gnome-2.6 view, or
> a gnome-2.8 view or a HEAD view.
> 
> I guess the best way to do this would be via dynamically generated
> pages, instead of the static HTML pages we have now.  In other words a
> nice pipe dream :)

Yes, that would require substantial changes to the current status pages.
I think Carlos accepts all patches. ;-)
However, I think he's already working on changing the status page
scripts from script-generated static pages to a database driven "view"
page setup, so I think it may be somewhat inline with what you're
thinking of aswell.


Christian