For the demo I've started with this
<
https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30>;. 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/1ZuD5fyOlGTVDh96jiuM6jTdofm4fG6gZqdfBN...
.
Martin
On Wed, Apr 10, 2019 at 11:10 AM Darran Lofthouse <
darran.lofthouse(a)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(a)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(a)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
>>>
>>>
>>>>