On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote:
> 2008/5/16 Thibaut Paumard <firstname.lastname@example.org>:
> > the topic has already been changed to "ssl security desaster", and in my
> > opinion this is precisely what my post is about: what can we learn from this
> > disaster. (More precisely, I'm giving my 2c on what level of patching is
> > acceptable in a Debian package. Since the disaster allegedly originates in
> > "abusive" patching, this is relevant).
> I disagree. The cause of the disaster was not that Debian does its own
> patching, but the fact that that patch was buggy. On the whole I think
> that Debian benefits a lot from custom patches, and in fact many
> packages would be severely buggy and/or wouldn't integrate properly
> with the rest of the system without them. It's not a secret that many
> projects benefit from Debian patches,
Do you mean "packages" instead of "projects" here? Or can you give an
> so there might be something good
> with them. Also, I don't think we should always wait for upstream's
> new releases for adding them if we have them available. It might
> depend on every case.
> Maybe there's a problem with the fact that some of those patches are
> 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).
That would probably help convince our users that we make sensible
changes, and would also allow upstream developers to browse our changes
easily (and comment/merge them).
| Lucas Nussbaum
| email@example.com http://www.lucas-nussbaum.net/ |
| jabber: firstname.lastname@example.org GPG: 1024D/023B3F4F |