Quoting Gerfried Fuchs (rhonda@deb.at): > Given that people expect a hopefully understandable stability of > backports because they are meant to be used with an otherwise stable > system I would like to know of your ideas and approaches you want to > apply to avoid these issues in the future. I actually assume the problems we had with samba and take the blame for mistakes that happened for some of them. I indeed learned a lot with this work and I probably have a much more reliable way to prepare them. Still, I don't think I messed up that much....and I think that all errors (often dependency problems with closely related libraries such as ctdb and tdb) were corrected with a very high priority. And, of course, I intend to keep the same commitment over the life of squeeze-backports. (if you go back in history, you'll also notice that I did my best to fix security issues in backports as soon as humanly possible...and we had quite a few in lenny) I still think it is good to have backports for samba because it gives our users a real choice between very strict stability in features..and breakage (by sticking with squeeze) and following the upstream "stable" releases (by following squeeze-backports). Given the complexity of samba, breakage and regressions are in some way unavoidable, particularly when a new major upstream enters the game (which should happen in a few weeks, when 3.6.0 is released). To give our users betters chances to avoid such breakage, I can for instance propose to pre-announce uploads of samba backports instead of "just" uploading them when the said package version enters testing in the main archive. I could even "pre-upload" such packages to a private area so that they can get more exposure and testing (real testing of samba is hard because most production systems serve dozens of clients.
Attachment:
signature.asc
Description: Digital signature