[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) Vincent -- Les gens heureux ne sont pas pressés. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
