On Wed, Aug 09, 2006 at 04:59:13PM +0200, Simon Richter wrote: > Well, if you hadn't been awake, the maintainers would have had to upload > a package with an ugly version number (or even an epoch), which would > not be the end of the world. Not everyone agrees with that :) > > Due to the craptacular nature of the process of doing UNACCEPTs (and the > > way it hurts buildds, confuses dak's internal structures, potentially > > confuses the BTS -- bugs closed on upload don't get reopened, etc), > > it's pretty rare that anyone is willing to do it too. > If this is becoming ftpmaster policy, please document the reasons for > it. I'm sorry, I'm not going to debate the merits of UNACCEPTing. Since the accepted queues have been in place, it's happened about four times -- less than once a year. We've regretted every single one of those, at least in part. The paragraph you quoted documents the reasons, in any case. > I can agree that certain things should not be done because of > limitations in scripts; The scripts do not handle UNACCEPTs, they're purely manual work, that's easy to do wrong, and routinely leaves things broken even when no mistakes are made. > > - losing the "accepted" queue entirely -- packages that are accepted > > go straight into the pool, removing one area for bugs to occur > > entirely > Well, I can see the need for queue support in the archive software [...] Yes, we have a range of queues -- unchecked, holding, new, byhand, p-u-new, embargoed, unembargoed, unchecked-disembargo, proposed-updates, done and reject. accepted is just one of them, though, thanks to the UNACCEPT issue, it's one that does collect problematic bugs. > > - allowing us to run the pulse more often than daily so that > > packages can be developed and deployed more rapidly, getting bugs > > found and fixed faster. this is particularly relevant for d-i, > > and has been for years now. > I'm not sure it scales that well if you apply it to the entire archive, > due to the overhead of the mirror pulse. It might make sense to have > "mini-pulses" for parts of the archive, such as d-i. There are difficulties, certainly, but nothing that can't be handled. None of this really helps avoid the problem though... Cheers, aj
Attachment:
signature.asc
Description: Digital signature