2008/5/16 Thibaut Paumard <[EMAIL PROTECTED]>: > 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, 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 defending the position of using pristine upstream source code are just a conservative position to guarantee that we can blame upstream or someone else if something like this happens again, not that bugs won't happen. Only those who don't do anything don't make mistakes. The point is to try to avoid mistakes, not to be able to blame upstream. Of course, the development and checking of the patches should be done as cooperatively with upstream as possible, as upstream might see something we're not seeing, but the way to the solution, in my opinion, is not to avoid patching but to develop a way to check them as extensively as possible. Maybe there should also be a clasification of packages according to how bad would a bug be in them for the whole system, so that patches in those could be more carefully reviewed. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]