How to handle Debian patches

[Guido Günther]

On Fri, May 16, 2008 at 04:04:20PM -0400, Joey Hess wrote:
> Raphael Hertzog wrote:
> > I totally agree that we need to make our changes more visible. In the
> > openssl case, the patch in question is inside the .diff.gz and you don't
> > notice it in the unpacked source package. I tend to give a look to what's
> > in debian/patches/ when I rebuild a package but not to what's in .diff.gz
> > only.
> > 
> > To me this one proof more than even when VCS are used to maintain
> > packages, our source packages must clearly identify the Debian patches
> > that are applied.
> 
> You're insinuatiog that a VCS does not allow easily browsing and
> examining patches, and I just don't buy it.

The current git version of git-dch allows to automatically prefix the
debian/changelog entries with git commit id's like:

 * [958c4b1] attach multipath.conf to bugreports
 * [2ac083e] make multipath-tools-boot arch all

This, together with the VCS-Browser/Git fields in debian/control makes
mapping the modifications to an easily reviewable patch quiet
comfortable. This is only a very special case, but could certainly be
done for other VCS too.
 -- Guido

> 
> > stating:
> > - a description of the patch and its purpose
> > - the associated bug number
> > - who wrote the patch
> > - where it has been forwarded upstream
> > - sign-off by reviewers maybe
> 
> All stuff that you get essentially for free by committing to a VCS.
> 
> > [2] And IMO we should go further than patches.d.o, we need to create a
> > cross-distro infrastructure where we can share patches. We really have to
> > show the way here... (we complained enough that ubuntu patches were
> > unusable, surely we can show how to do it right when it comes to sharing
> > patches with others and upstream)
> 
> We didn't just complain that Ubuntu's patches were unusable, but that
> their whole means of communication of them back to upstream, ie Debian,
> was/is flawed. We [1] complained that automatically publishing patches was
> not sufficient to get those patches integrated back into Debian because --
> 
> a) People cannot be expected to poll a directory somewhere for new
>    patches.
>    (Which Ubuntu has partially addressed, if your proposal does, it's
>    not clear to me specifically how.)
> b) Monolithic patches that make multiple changes are near-useless.
>    (Which Ubuntu has not satisfactorally addressed, IMHO; I still get
>    automated patch mails with multiple changes in them. Your propsal
>    tries to address this.)
> c) Patches lacked explanations of why changes were made, beyond the
>    changelog, and it was difficult to figure out more.
>    (Which Ubuntu has not particularly addressed, and I'm not sure your
>    proposal addresses entirely..)
> d) The best way to get good code is to go out and get in communication
>    with upstream about it, explain the rationalle so that they can fully
>    understand it, and take their advice into account.
>    (Which Ubuntu maintainers generally still fail to do with Debian, and
>    which your proposal doesn't really facilitate Debian doing more than
>    we do now.)
> 
> 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?
> 
> -- 
> see shy jo
> 
> [1] specifically, me



-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST at lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org