On Wed, Jul 24, 2019 at 02:13:02PM +0100, Tom Hughes wrote: > On 24/07/2019 13:32, Josh Boyer wrote: > > On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > > > > > On 24. 07. 19 10:24, Tom Hughes wrote: > > > > That said, having to go round adding a mega ugly config file > > > > to every package that looks an awful lot like an internal braindump > > > > from some system doesn't really inspire confidence, or make for an > > > > easy way of opting in. > > > > > > This. The gating.yaml file is terrible. > > > > Do either of you have a better suggestion? > > Well more ordinary YAML would be a good start. > > I mean I literally had to go and try and read the YAML spec > to try and work out what it was doing and let me tell you, for > something that I had always thought was a simple format it has > a very long and hard to read spec... > > So a single document would be good, and get rid of the tags > which I assume are the result of serialising objects with > those name. > > The very.long.reverse.domain.test.names are not ideal. Agreed, we could look for better ones. > Then there's decision_context which apparently does nothing > but has to be there. It is used! It is what define which tests are used to gate the build/update when entering the -testing repo vs which ones are used to gate entering the -stable repo. > Is there any rule type other than PassingTestCaseRule? There actually are others: https://docs.pagure.org/greenwave/policies.html There is the one that is used to pull policies from remote locations (which is what is used to allow package-specific rules) and we had another one in the past to allow, globally, certain rules to apply only to some packages. That being said, maybe there would be a way to simplify the syntax for remote policies, so I've opened a ticket to greenwave to see what they think about it and if it is doable: https://pagure.io/greenwave/issue/465 Thanks for your feedback :) Pierre _______________________________________________ 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
