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

Re: How to handle Debian patches



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.

> 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

Attachment: signature.asc
Description: Digital signature


Reply to: