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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org