For the demo I've started with this. For additional checks I have only something to verify that issue in title matches the link in the description. Any ideas are welcome!

I was also thinking about making distinction between issues / bugs and features if that would be useful.

I've created a google document to track this - https://docs.google.com/document/d/1ZuD5fyOlGTVDh96jiuM6jTdofm4fG6gZqdfBNRdZp8I/edit?usp=sharing.

Martin


On Wed, Apr 10, 2019 at 11:10 AM Darran Lofthouse <darran.lofthouse@jboss.com> wrote:
Do we have somewhere yet that we can start to look into an initial set of rules to discuss what the initial set should be?

On Wed, Apr 10, 2019 at 6:32 AM Martin Stefanko <mstefank@redhat.com> wrote:
> The time the cross becomes a problem is if we adopt a set of verification rules that we know will regularly trigger a failure to be ignored, if the failure cases to be ignored are truly exceptional cases then the cross will be useful.

It would be beneficial to adjust rules as we'll see how useful they are as time progresses. Configuration of rules is external to the service so it will be possible.

Martin 


On Tue, Apr 9, 2019 at 5:49 PM Darran Lofthouse <darran.lofthouse@jboss.com> wrote:
> OTOH if the mergers decide they want to do something I don't want a tool preventing us doing it, which is what my questions were driving at. We're way smarter than the tool.

The status should not prevent a possibility of merge but if the cross next to the commit would be a problem we can add an override to disable tyr check (meaning make it pass manually) with a comment or similar as suggested above.

The time the cross becomes a problem is if we adopt a set of verification rules that we know will regularly trigger a failure to be ignored, if the failure cases to be ignored are truly exceptional cases then the cross will be useful.
 

Martin