Quoting Gerfried Fuchs (rhonda@deb.at): > Of course quick responses are extremely helpful to mitigate the issues. > It though doesn't mean the issues didn't happen in the first place. Of > the 22 lenny-bpo uploads, 14 were +1 uploads, 7 (the half of them) > required a +2, and one upload even a +3. And those didn't happen only in > the first uploads, they are spread across the whole range, two of the > last three uploads needed a +2: > <http://backports.debian.org/dumps/lenny-backports.dump> Yes. This is where I think I improved my processes in many ways. > > 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). > > Do you expect more breakage with respect to the backports than what > would hit a user that is later regularly upgrading from squeeze to > wheezy? Somehow this makes it feel that you see backports as kinda > testbed for upgrade issues. Please tell me that I got the wrong > impression here. No, not at all. Backports purpose is to allow users of stable to be able to use the latest upstream version (with, of course, the primary filter of the said version to be uploaded in unstable and receive enough testing and debugging for being trasitioned to testing). For instance, during the last months before we released squeeze, they were the only way for users of stable to setup domain controllers with Windows 7 clients. In the latest release cycle, they have been an invaluable help in narrowing problems reported by users of stable against the version of samba *in stable*. Very often, these users could try to reproduce the issue they were facing with our backported version. That made interaction with upstream considerably easier, avoiding us to report bugs that are, from upstream POV, fixed for quite some time. Then, in some situations, such fixes were even included in proposed-updates uploads. > > > 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. > > I think that might indeed be useful, and actually it could reduce your > overhead: You could prepare them simultaneously with the upload to > unstable in your area, giving brave early-birds the chance to send you > feedback right ahead before the package even hits the backports pool. If > you need help with setting up such a thing with reprepro or similar, I > would offer a helping hand to get it started. We actually have a private repository on http://pkg-samba.alioth.d.o which was setup two years ago by Luk Clease. There we (I) maintain another set of "backports": those that do not fit prerequisites for official backports (most of the time because they aren't in testing). So, indeed, adding another branch there is kinda trivial, even for me..:-). I'll try using such new place to put packages meant to be uploaded on bpo. I once described the overall picture of samba packages in Debian and "around" Debian in a blog post. It should indeed be easy to retrieve from my blog at http://www.perrier.eu.org/weblog (among dozens of posts about running here or there). > > For now I approved the package - please at least do an install test > before you upload, I know that samba has a lot of different setup > possibilities, but I guess you use it in a squeeze environment somewhere > yourself. Thanks for approving the upload. As said, these packages are actually running on a pool of 4 print servers at Onera, serving a little bit less than 400 printers to about 2000 workstations. These servers are "pure squeeze" with only samba coming from outside the main archive. I really consider this as a quite solid testcase. Much more solid, indeed, than my usual testcase : my server at home with only 1 printer, a few file shares and only one Windows client (but this client has her own specific ways to punish me if I'm screwing her file accesses).
Attachment:
signature.asc
Description: Digital signature