Adam Williamson wrote:
But the key principle here isn't 'fairness', it's
'is the package
broken'. That's the actual thing we're trying to achieve. From that
perspective it doesn't make any sense to start the timer on submission
rather than push.
What I want to achieve is predictability for the maintainer, so that they
can know from the onstart when they will be able to push their package to
stable. This is particularly important if they need to meet some internal
(freeze, release EOL, etc.) or external deadline with the stable push, but
it is also generally a useful property.
I also believe that 7 days are already quite long and so (7 days minus
infrastructure delays) should be enough time to test the package. If not,
then the infrastructure delays are too long, so blame rel-eng or infra for
any updates that would sneak through due to insufficient testing, not the
maintainer.
The best way to avoid the problem you identify is to make the
updates
pushes faster and more reliable.
That is also the best way to avoid the problem you identify in my proposal.
:-)
Kevin Kofler