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

Re: How to handle Debian patches

Le samedi 17 mai 2008, à 15:24 +0200, Pierre Habouzit a écrit :
> On Sat, May 17, 2008 at 12:07:43PM +0000, Vincent Untz wrote:
> > [I'm not subscribed to debian-devel, so feel free to cc me if you want
> > to keep me in the loop]
> done.
> >  + 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)
>   We will never ever harmonize on one vcs in Debian. Don't dream of it,
> it just won't work. Even Ubuntu can't do that (okay they use bzr a _lot_
> but I know quite a few Ubuntu developers that use git instead so…).

Sorry, my point wasn't clear: I'm not suggesting that Debian developers
should harmonize on one vcs. I was merely saying that if multiple vcs
are used, you shouldn't expect upstream to be happy about having to go
to multiple places to find the patches for debian packages (unless
all those places are integrated in some way in one unique place

>   FWIW I agree that the .diff.gz is a terrible way of exposing our
> modifications to the world, espcially since all is meld into that
> (debian/ specific changes not meant to be merged upstream like packaging
> stuff, or real patches that upstream should probably take). That's
> exactly why while I'm doing most of my work in git, I try to export
> patches in debian/patches sanely, and I usually also export a git
> branch, trivially browsable through my git.madism.org gitweb, hence
> without _any_ git knowledge, for upstreams to cherry-pick from. Sadly
> not everyone agrees that serializing changes we do is the way to go, and
> the latter (publishing my branch in a gitweb) isn't normalized, and
> won't probably ever be, or not under this form.

It's not about git knowledge (which is also an important point, but the
web interfaces makes it easy to solve it), it's about having to go to
git.madism.org for one debian package, git.blabla.org for another debian
package and then bzr.blablabla.org for a third debian package. Having a
central place helps.

>   The sole thing that can work is that the source package is good enough
> for everyone wanting to grok what is in our packages, because that's the
> _SOLE_ thing everyone still uses in the end. Our source format is our
> common point, it's the best place to make things like that happen.

Kind of agree, yes. Except that when I check the patches for 10 modules
I maintain in 5 distros, I find it more convenient to have something
like http://patches.ubuntu.com/, http://cvs.fedoraproject.org/viewcvs/
or http://sources.gentoo.org/viewcvs.py/gentoo-x86/ to quickly look at
everything. (but I'd be the first to agree that this method is
suboptimal too and that all distros could do a better job)

Just my €0.02 :-)


Les gens heureux ne sont pas pressés.

Reply to: