Branching - Fedora packages!

[Miloslav Trmač]

Ankitkumar Rameshchandra Patel píše v Čt 15. 01. 2009 v 16:35 +0530:
> 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.
No, we don't have the manpower to maintain code of older Fedora releases
in branches - and even if we "can" do it, we'd generally prefer to focus
the effort to develop new features for the next release instead.

> > 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
We do "maintain" it, but "maintain" does not mean "branch and develop
new features".  It means "fix bugs that impact users enough to warrant
it".

A few quotes:
http://fedoraproject.org/wiki/FAQ#What_is_the_errata_or_updates_policy_for_The_Fedora_Project.3F 
> Availability of updates should not be misconstrued as support for
> anything other than continued development and innovation of the code
> base.  


https://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
> Fast incremental improvements - Staying close to upstream versions is
> helpful when doing version bumps for updates that bring in new
> features. This prevents tedious backporting of only security and bug
> fixes. Deviations from upstream can significantly hamper the speed of
> delivering improvements from new versions to end users.


> > > 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.
That's not what I mean.  Assume the tools are ready today.  How many F10
packages would receive a translation update in the following 6 months?
(To be fair, I have no idea.  All I can say is that I personally won't
work on any translations but the upstream "head".  Perhaps other
translators can add their estimates?)

The solution for one update per release and 300 updates per release
needs to be different.

> > > 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?
For a released Fedora version?  Yes, if it happens reasonably
infrequently.  For more frequent translation updates I'd probably want
to batch them, releasing an update for a single package perhaps once a
month.

> > 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.
Yes, and it is also more difficult to do; I can't think of a way that
wouldn't result in a very massive disruption of the development process
(basically, every package that contains translations would need to be
manually edited.)  Again, how much is it likely to be used?

> > _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.
Right.  And note that deviation from upstream, along with the potential
for controversy, is implied in what you want to do.
	Mirek