Hi, Le 16 mai 08 à 13:48, Martin Uecker a écrit :
"Kevin B. McCarty" <kmccarty@debian.org> wrote:If you see packages for which a Debian-specific patch seems unnecessary, please by all means file a bug (severity wishlist) requesting that thepatch be either reverted or submitted upstream.Most time the patch is already submitted upstream, but not yet applied or released. If you look into the Debian changelogs you find a lot of "drop XXX patch, applied upstream". This is done to bring the fix faster to the user. The question is, is this worth it? Maybe it is, but only for certain patches? Is there a policy?
I personally often discuss the patches with my upstream (but then, they're really responsive). Most of the time they apply it to their CVS, and I backport their patch (generally improved over my approach). If a patch fixes a real bug and looks simple enough that's its unlikely to break anything, I think it's useful. Other patches are not supposed to go to upstream, because they are just meant to implement the Debian policy (also I generally tell upstream anyway, to have their opinion).
Of course you need to define "simple enough", and "unlikely" (for openssl, you want it to be _very_ unlikely). I agree with you that patching should be kept to a minimum : back-porting bug fixes and implementing Debian policy (even there, I would try to not overdo it, but a "must" in policy is a must).
By the way, Debian policy is not completely silly, so even those patches can often go to upstream and be shared with the other distributions, of be configurable at build time. For instance, my main package, yorick, traditionally expects user files to be in ~/ Yorick/. Those files can be considered configuration or data, that really depends on the user. I've triggered a discussion on the matter that configuration files in a user's home directory should be stored in hidden files or directories (that's from the FHS). Yorick now looks at both ~/.yorick/ and ~/Yorick/, so the user can choose. I was motivated by abiding by Debian policy, but the change was made upstream, to avoid a fork. If upstream had rejected the idea, I'm not sure what I would have chosen. I tend to believe the right thing to do here was to avoid a fork at all cost, but others may disagree.
Let's hope this discussion will, in the end, bring good ideas and trigger actual work to improve Debian, and perhaps the free software community at large.
Best regards, Thibaut.