Re: How to handle Debian patches
[I'm not subscribed to debian-devel, so feel free to cc me if you want
to keep me in the loop]
Le samedi 17 mai 2008, à 00:19 +0200, Raphael Hertzog a écrit :
> On Fri, 16 May 2008, Joey Hess wrote:
> > I can certianly see some good benefits to the lines that you're
> > thinking, but if this turns into a pile of patches on a website that
> > upstream has to manually go find, and rarely does, and a lot of busywork
> > keeping the patches up-to-date, and maintaining redundant metadata ... then
> > why would I want to use that when I can shoot a mail off to upstream
> > with a git-format-patch in it?
> Certainly patches.d.o is not meant to replace direct interaction with
> upstream developers but it would be a nice service for upstream developers
> when the debian maintainer sucks (and it happens...) and also for other
> distributions that can benefit from our work.
> But when we give away patches, we also like to get patches from other back
> so that's why I believe that if we design any patch sharing
> infrastructure, we must open it from the beginning to other distributions
> so that we actually benefit from it too.
Here are some comments, with my upstream hat:
+ as some people already pointed out, the current situation with
diff.gz is far from being optimal. I know I'm following packages for
things I maintain in major distributions to see how it's getting
patched. It turns out that for debian, the only useful resource for
me is http://patches.ubuntu.com/by-release/extracted/debian/
+ looks like some people think a patches.debian.org wouldn't be useful.
I'd bet that most upstream people would find it useful. Sure, it
might not be the best approach for everybody, but at least it's dead
simple for upstream. You can build upon that later.
+ it also seems that some debian developers would prefer the VCS way
instead of patches.debian.org. Well, if all the debian packages are
maintained with the same VCS, and it's easy to browse this from one
place, then yes. Else, if I have to use git for $a, bzr for $b, svn
for $c, hg for $d, etc., this is going to be a nightmare from my
upstream point of view. (although it'd be fine, I guess, to have
$vcs_a for $distro_a and $vcs_b for $distro_b -- the important point
is that consistency to access patches for all packages in a given
distro is key for upstream people)
(On a more general note, I really believe this is something that could
be solved in a cross-distro way. Being able to do "lspatches
--all-distros $module" would rock)
Les gens heureux ne sont pas pressés.