Re: gpdf string freeze breakages

[Christian Rose <menthos gnome org>]

tis 2004-05-04 klockan 23.27 skrev Carlos Perelló Marín:
> El mar, 04-05-2004 a las 22:12, +0200, Rémi Cohen-Scali escribió:
> > This is a wonderfull status page. But  it is  very translation oriented 
> > and really very  complete (with several views).
> > I hope (for the maintainer) it is generated ;-).
> 
> Yes it's generated  every 8 hours.
> 
> > Seriously it is very nice but I was thinking to something simpler and 
> > more developer oriented.
> 
> The status pages are evolving all time (not as fast as I could want) but
> they are evolving and I think that you want those pages to not break the
> freeze again, with status pages is easy, don't touch the GNOME 2.6
> modules listed there ;-)
> 
> Please, don't create a new place to store the same information, we have
> already the releng module list (it's only update with a new release),
> the jhbuild .xml definition file and the status pages "database" (it's
> now a .xml file but it's evolving into a database). If you create your
> own web pages, try to reuse some of the already available "backends",
> it's not an easy task update the development branches.

I think this is exactly the problem: There are clearly too many sources
for release information that all need updating.

When a maintainer decides to branch, he needs to update jhbuild, tell
the release team, tell the translators, tell the docs people, the
accessibility people, and tell everyone else and their house cat¹ aswell
about the new branch.
Then all these people in the release team and the subprojects need to
update "their" sources with this information aswell: The module list,
the translation status pages, the doctable, and so on. This duplication
and manual distribution of information is so very prone to errors and
accidents.
The translation status pages are actually good examples on this; they're
only as uptodate as some translation people² keep them, using whatever
branching information they happen to get. Also, they only contain
modules with translatable content: Other modules that still are affected
by other freezes aren't monitored.


I think much could be won if the release team could have some central
easily queryable releng database, be it in a XML file or whatnot, that
everyone else could automatically fetch, parse and extract information
from; like jhbuild, the translation status pages and every other
second-level source.
It could contain information about what pieces of software is included
in the releases, the repositories where said software is hosted if it's
outside of GNOME CVS, the module name it uses in said repository, what
branch it uses for that release, who the maintainers are, if it has
translateable content, if it needs to have user/developer documentation,
and so on. Then it would be trivial to extract that information to the
translation status pages and the doctable, as an example.
Also, it would be much easier to keep uptodate.
http://www.gnome.org/start/2.5/modules/ still lists HEAD for all the
modules -- if that information had been in a central releng database, it
would be trivial to change the branch once and for all without
forgetting to do it in some place or informing someone.


Christian



¹ Or whatever pet they have.
² Which is basically me, sometimes with the help of others.