[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc and UNACCEPTs

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...


Attachment: signature.asc
Description: Digital signature

Reply to: