How to handle Debian patches

[martin f krafft]

Please Cc vcs-pkg-discuss at lists.alioth.debian.org on this thread!

Including the full response for the list.

also sprach Raphael Hertzog <hertzog at debian.org> [2008.05.16.1654 +0100]:
> [Breaking the thread on purpose to start a new one]
> 
> On Fri, 16 May 2008, Lucas Nussbaum wrote:
> > On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote:
> > > just reviewed by just one person, but then again, I seriously think
> > > that it would have been quite difficult to discover that there was a
> > > problem with this one. The proof that it wasn't evident is not only
> > > that upstream didn't see the problem either, nor any other developer
> > > or derivative distribution or independent reviewers in 2 years.
> > 
> > I think that one problem is that our patches are too difficult to
> > review. We should make our Debian-specific changes more visible,
> > comment them, etc.
> > 
> > We could write a diff2html tool that would help read our diff.gz files
> > by separating packaging changes from changes made to upstream source,
> > and then publish that information on a patches.d.o service, and link it
> > from various places (packages.d.o, PTS).
> 
> 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. The source package is an export format of our packaging
> work and they must highlight our changes so that other people can easily
> grab our changes and/or review them. [1]
> 
> In the general case, I do believe that the new source package format "3.0
> (quilt)" will help as all Debian specific changes will always end up in
> debian/patches/. Any manual change leads to a new patch that will be
> associated to the version where it has been introduced so it's easy to
> look the changelog to find the explanation of the change (if any). And
> patches directly installed in debian/patches ought to be documented (see
> below for more on this).
> 
> Once we switched to this source format, it should be trivial to create
> patches.debian.org. [2]
> 
> Add to this that each patch should have some standardized header on top
> 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
> 
> Someone recently posted an example of this. IMO we should write a DEP
> on patch management and standardize those headers. And probably enforce
> their usage for patches on sensitive packages (lintian checks?).
> 
> Cheers,
> 
> [1] It has a cost but I believe it's worth it. And we need to work on
> tools that let us handle our changes in topic branches and yet still
> generate a package which is a plain upstream tarball + a series of patches.
> 
> [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)
> -- 
> Raphaël Hertzog
> 
> Le best-seller français mis à jour pour Debian Etch :
> http://www.ouaza.com/livre/admin-debian/
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-REQUEST at lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org
> 


-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"a mathematician is a device for turning coffee into theorems."
                                                         -- paul erdös
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20080516/2eb5f53a/attachment.pgp