Re: Status page HEAD category?

[Carlos Perelló Marín <carlos gnome org>]

El jue, 15-04-2004 a las 12:52, Christian Rose escribió:
Hi

[...]

> > 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.

Yes I'm developing it as dynamic webpages now but not only the webpages
but the .po/.pot refresh so we will relay on cvs-commits-list mails and
will get automatically refresh every time a modification is committed
instead of a timed update for all modules.

My .procmailrc + awk hacking seems to be working right and I'm filling
the database automatically from cvs commits, I have already:

stats-l10n=# SELECT count(*) from module;
 count
-------
   205
(1 row)

stats-l10n=# SELECT count(*) from version;
 count
-------
   225
(1 row)

stats-l10n=# SELECT count(*) from pot;
 count
-------
   112
(1 row)

That information was added automatically so we will detect new
branches/modules and new directories with translations as soon as they
are committed. The only "problem" I have is that new branches are not
detected until someone commits something to the branch, the branch
creation does not sends an email, thus, that part will need manual
input.

It now also supports external CVS servers, it's just a matter of
configure it (as soon as the scripts are finished, of course).

With those changes I hope we will remove the resources limitation
because we will update only modules that have changes. Also, my company
will give us a virtual server (UserModeLinux) hosted on a new server we
just acquired, as we have dynamic pages and a postgresql database to
serve the data, the actual system will not be valid anymore (build stats
in my home server and upload static pages to widget.gnome.org).
Christian, we will need an external developer.gnome.org domain, what
about l10n.gnome.org/stats? or something like that?

I'm migrating now my company information to the new server and preparing
our UML, hope this weekend we could start testing the new system (the
old one will be working until the new ones have the same features and we
don't lose any one).

As a comment, the web pages are developed as a PHP script and the system
updates and commits are a mix of bash + awk + C programs with libgda to
change the database. You can see the database schema here:
http://carlos.pemas.net/svn/public/translation-stats/trunk/data/database.sql

The C code inside translation-stats is not the latest one, that one is
from an older version.

Cheers.


> 
> 
> Christian
> 
> _______________________________________________
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://lists.gnome.org/mailman/listinfo/gnome-i18n
-- 
Carlos Perelló Marín
Debian GNU/Linux Sid (PowerPC)
Linux Registered User #121232
mailto:carlos@pemas.net || mailto:carlos@gnome.org
http://carlos.pemas.net
Valencia - Spain