FESCo Meeting Minutes 2006-08-31

Jesse Keating jkeating at redhat.com
Fri Sep 1 17:07:13 UTC 2006


On Fri, 2006-09-01 at 07:32 -0700, Toshio Kuratomi wrote:
> What makes it lengthy?  Looking at the two files, the only difference is
> that all the translatable fields are changed from <_TAG> to <TAG>.
> Can't we make extracting the translatable strings and creating the
> comps-feX.xml.in file two separate steps?

In core land, the .in file is ran through a bunch of translation .po
files to generate translated group texts.  If more groups get added to
extras, we're going to need to translate them.

> Also, the live comps file is currently not synced with commits to
> the .in file.  So it needs to be regenerated at some point anyway...

Yes, we do that in Core land too, we generate it when we make changes to
the .in file.

> Also, what involves the comps file in the sign/push process anyway? Is
> it repoview?  Isn't the plan to move repoview out to its own async
> process?

I do believe the comps file needs to be referenced when repodata is
created so that group actions work, and they show up correctly in Pirut
and such.  When we do a rawhide push, the comps file is pulled out of
CVS (the translated one) and that is used with createrepo.  In extras
land, if you don't keep the translated comps file in CVS or somewhere
else, it will have to be generated on the fly from the .in file and used
during the createrepo phase.

> Alternately, the script that generates comps-feX.xml could place the
> file in another directory (perhaps the same one as the translated comps)
> so that people editing the files aren't confused as to which file they
> need to edit. 

This is a possible solution, yes.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060901/0effadc7/attachment.sig>


More information about the fedora-extras-list mailing list