Fudcon - Items for discussion

Bill Nottingham notting at redhat.com
Sat Jan 6 03:17:41 UTC 2007


Toshio Kuratomi (a.badger at gmail.com) said: 
> > i18n/elvis/rhlinux migration.
> 
> Could we have someone at FudCon to give us a tour of what all is in need
> of migration?  I know that there's a bunch of infrastructure there that
> needs to move but don't have a clear idea of just what it is.

What's On Elvis:

1) a CVS server. Self-explanatory.
  - includes pserver (aiyeeee!)
  - includes sanity checks on translation checkin
  - includes ACLs for translators so they don't commit to other languages
2) Accounts (ssh v2 keys), split into two groups:
  - general write access
  - translators (write access to .po files only)
3) the translation system, which has:
  - its own separate account database (postgresql) on top. tracking:
    - translators
    - their keys
    - their .htpasswds
    - languages
    - translator/language mappings
    - module statuses
    - translator status (active, suspended, etc)
  - web frontend
    - showing translation status
    - allowing you to 'reserve' files

#1 is pretty easy.

#2, well, we know how we're going to tackle that.

#3 is all written in perl (which has its good and bad points.) However,
since it's written around a database which needs to die, I'm not sure
it's useful at all.

So, what we need is:

- translators in the account system
- a way to describe in the account system what langauges a translator
  is responsible for
- a way to enforce that when checkins are done

Frankly, I'm of the opinion that most of the rest of the stuff
can be scrapped as is and can be replaced by something like
damned-lies (progress.gnome.org). In fact, asking other projects
what sort of software they use around their translation couldn't
hurt.

One thing we'll need is a way to integrate this translation
framework across multiple SCMs - I'd like to be able to handle
software whether it's in git, svn, cvs, or hg. We'll also need
a better group organization aside from just 'put everyone in
cvsfedora'.

Bill




More information about the Fedora-infrastructure-list mailing list