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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
