Branching - Fedora packages!

Ankitkumar Rameshchandra Patel ankit at redhat.com
Thu Jan 15 11:05:00 UTC 2009


Miloslav Trmač wrote:
> Ankitkumar Rameshchandra Patel píše v Čt 15. 01. 2009 v 14:28 +0530: 
>   
>> I think I didn't make it very clear. The context here is for core
>> Fedora packages only, which are maintained on the fedorahosted
>> servers.
>>     
> No matter.  Most packages don't have branches for code now, and if the
> package is ever updated in Fedora 9, it is usually either a quite small
> patch (not a new tarball from any VCS), or a full rebase to the most
> recent upstream release.  In _neither_ case will the developer want to
> use the code on a "Fedora 9" branch" of the package, so they will not
> pull in any translations from such a branch.  
That's because we don't have such process or may be tools in place.
> Fedora maintainers are not
> expected to create branches for every release and maintain them
> individually, Fedora does quite frequent releases and all features are
> expected to get in Fedora "in the next release"; the same should apply
> to translations IMHO. (There are a few exceptions that have branches
> like anaconda, but specifically anaconda is a special case because full
> rebases of the installation program are very risky).
>
>   
We maintain any given release X until one month after the release of 
X+2. http://fedoraproject.org/wiki/LifeCycle
>>> I can't see why the same mechanism shouldn't work for translations
>>> as
>>> well: Just create an updated .po file (or a patch that only changes
>>> a
>>> few specific messages), file a bug at bugzilla.redhat.com asking for
>>> a
>>> package update that uses that .po file.  
>>>       
>> We have 80+ languages in FLP. and a number of packages.
>>     
> How many of those are _actually_ likely to be updated in Fedora post
> factum?
>
>   
Try to provide the feature which can help them update previous translations.
>> Translators are not the techies. They can download translation file =>
>> translate it => submit it. Doing patches, VCS checkouts, commits tend
>> to reduce their interest.
>>     
> Right, getting a .pot file to translate against for an older Fedora
> release might really be difficult (but comparatively easy to solve -
> just copy them all from transifex to a directory available over HTTP at
> release time).  But there's no need for any commits - just submit the
> full .po file to bugzilla.
>
>   
Alright, so will you accept Punjabi translation for your package if I 
translate & attach it in the bug?
>>> This doesn't let you use
>>> transifex's statistics or submission interface - but (at least in
>>> Fedora), translations are very rarely updated for older versions.
>>>       
>> I don't see transifex provides the facility to submit translation of
>> packages which are not branched for Fedora 10 or 9 or earlier release.
>>     
> Submitting a translation to a branch _doesn't solve your problem_.  On
> HEAD, the simple act of submitting a translation via Transifex ensures
> that it will be (eventually) included in a released package.  On a
> branch, it doesn't: you must let the package maintainer know that there
> is a new translation available and the package maintainer must manually
> create a new package.
>
> If you are already dead set on updating amount of translations (say more
> than one translation update per package a month) after the release, you
> need to argue for separating the translations from the packages they
> translate, and to get someone to develop a completely automated
> mechanism for shipping the translation updates to final users.  Until
> that is done, the system - with package maintainers manually building
> updates that can contain new translations - can not handle 20
> translation teams that decide to translate Fedora 9 a month after its
> release.  
That sounds better actually, since it gives complete control over to the 
translators over the translations they are doing. They don't need to 
wait for anyone to make their translations live.
> We also really can't migrate to such a mechanism for Fedora
> 10, and probably not even for Fedora 11.
>   
Now, this makes me nervous again. :(
> _And even if you do this_ and decouple translation updates from
> "software" updates, "upstream" for most packages (on fedorahosted.org or
> not) still won't be interested in the translation!  You'll need to do
> what Launchpad does, and store the translations in a Fedora-specific
> storage, away from any upstream repository.
>   
Launchpad has it's own set of issues that I don't want to get into.
> To sum up: Either the volume of translation updates is small enough that
> the complete process can be done manually, or you need to persuade
> Fedora to make a major change to the way packages are delivered - in
> that case branching anything in fedorahosted or Transifex is far from
> the first step.
>   
Well, I am fine with any of these options as long as they solve the 
issue. But, anything we come to the conclusion should be best for Fedora 
(Users, Community, Project, Developers, Localizers, everyone who is Fedora).
> 	Mirek
>
>   
Thanks!

-- 
Regards,
Ankit Patel
http://www.indianoss.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/trans/attachments/20090115/23651012/attachment.html 


More information about the trans mailing list