Re: Status page HEAD category?
- From: Gareth Owen <gowen72 yahoo com>
- To: Christian Rose <menthos gnome org>
- Cc: Adam Weinberger <adamw magnesium net>,GNOME I18N List <gnome-i18n gnome org>
- Subject: Re: Status page HEAD category?
- Date: Wed, 14 Apr 2004 13:31:27 -0400
On Wed, 2004-04-14 at 17:33, Christian Rose wrote:
> ons 2004-04-14 klockan 22.27 skrev Adam Weinberger:
> > What if, instead, there were a separate HEAD category, and it always
> > contained the development branch. Then, it could be copied into a 2.8
> > category once 2.8 branchpoints are tagged.
>
> 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.
For example there presumably is a branch for supporting the stable
evolution 1.4 release, but this isn't tracked by the status pages.
> 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. 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.
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 :)
--
Gareth Owen <gowen72@yahoo.com>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]