[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: moto4lin, I give up.



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]