Please Cc vcs-pkg-discuss@lists.alioth.debian.org on this thread!
Including the full response for the list.
also sprach Raphael Hertzog <hertzog@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@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
.''`. martin f. krafft <madduck@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
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)