moto4lin, I give up.

Hans de Goede j.w.r.degoede at hhs.nl
Sat Dec 29 06:59:17 UTC 2007


Kevin Kofler wrote:
> dragonauta x <dragonauta.x <at> gmail.com> writes:
>> This is what I got on bugzilla:"I'm sorry, but this is still an upstream
>> issue.  The fact that the upstream author has a patch that fixes this problem
>> but is not releasing it in anofficial release does not make this a packaging
>> issues, IMHO.
> 
> IMHO it does. Maintainers: In a situation like this, if there's a patch from 
> upstream, please apply it!
> 
> If upstream only provides the fix in the form of a commit to SVN trunk, first 
> try applying the diff from SVN to the release, sometimes it just works. If it 
> doesn't apply, you have 3 options:
> 1. Try asking upstream (nicely) for a backport which applies to the stable 
> release. Keep in mind though that the upstream author(s) might be very busy and 
> do(es) not necessarily have the time to do backports.
> 2. Backport the patch yourself. This is often fairly easy.
> 3. Upgrade to a SVN snapshot wholesale. If upstream hasn't done any real 
> release for ages, this may well be the best option, however be careful, as the 
> snapshot may also include regressions. It is usually a good idea to run the 
> idea by upstream first, as for one they are likely to know about any 
> regressions in the snapshots, and secondly, unfortunately some uncooperative 
> upstreams may also get upset and hostile if you package snapshots (whereas 
> others will even ask you to do just that, also depending on the state the code 
> in SVN is in, thus the importance of asking).
> 
> If you have a ready-to-apply patch or if you use options 1 or 2, please don't 
> patch the source tarball directly, use Patch0 (or Patch1, ...). If you use 
> option 3, make your SVN checkout the new Source0.
>

You forgot 4) Ask on this list if there is anyone who is willing to 
backport upstream's fix for you.

>> It is my position that bugs like this need to be fixed by an upstream
>> release, particularly in cases like this.  Because upstream fixes help all
>> distributions,and Fedora, effectively, forking it does not.
> 
> First of all: It isn't "forking" to backport a patch which is already in the 
> upstream SVN trunk. It's even less "forking" to package something straight from 
> the SVN trunk.
> 
> Secondly: Other distros will eventually get the fix because it's already in SVN 
> trunk, so it will be in the next release. And if they want it first, they can 
> backport it, just as you can.
> 
> Notwithstanding all the above: It would of course be better for all distros, 
> including Fedora, if there was a new stable release with the fix. However, as I 
> said above, upstream may be too busy to do backports, and unwilling to release 
> from the current state of the SVN trunk for reasons unrelated to the fix 
> (regressions etc.). So sometimes, backporting is really the only option.
> 
>> I don't believe it is Fedora's place to be tracking svn.
> 
> Then backport the fix.
> 
> If it doesn't apply to the stable version and you can't get it to apply, let us 
> see the BZ report and the fix and I'm sure one of us will be able to help you.
> 

Ah yes, thats what I meant with option 4.

Regards,

Hans




More information about the fedora-devel-list mailing list