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

Re: glibc and UNACCEPTs


Anthony Towns wrote:

> It worked because I was awake at 4:20am localtime, on IRC to notice,
> and willing to do something about it... While that's more common than is
> probably good, it's not something I like to see the release depend on...

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.

> 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 can agree that certain things should not be done because of
limitations in scripts; however policy has a tendency to be interpreted
the other way 'round in retrospect, so that the policy of not doing
UNACCEPTs was there first, and that it is therefore not desirable to
implement the feature in the scripts because, well, such a feature would
be against the policy anyway.

>      - 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
nevertheless, specifically for security, so I'm not sure you can reduce
the complexity of the system by allowing "queue-less" archives. It will
add more complexity to mirror handling at least.

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


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: