How to handle Debian patches
[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/
Reply to: