Re: The wider implications of debhelper/dbus breakage
Wouter Verhelst a écrit :
>>> Ah, so this is about not interfering with testing migration, I guess?
>> It's not only testing migration. As an example: If you have a large chain
>> of binNMUs which all need some dep-wait on a package upper in the chain
>> you get the effect that the whole thing takes several days just because
>> each step of the chain first blocks on signing and uploading once a day to
>> do the next one.
> How often does that happen? (serious question, I have no clue)
I will speak with my OCaml maitainer's hat, but what I say is not really
specific to OCaml.
For example, each OCaml transition involve rebuilding a lot of packages
(about 139), with 6 levels of dependencies. So if some build takes 2
days or more (for the current transition, on some builds, it was even
more than a week) to be uploaded, it means that transition will last at
least 12 days (for the current transition, all packages were
rebuilt/uploaded/installed after 21 days). But most of the builds are
successful (and fast). If packages were automatically uploaded on
success, a dependency level would be cleared at each dinstall run,
meaning the whole recompilation would take less than 2 days.
Now, imagine that during this transition, another long transition (for
another library) starts... The new transition can be entangled with the
first one, delaying it even further.