<div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div>+1 to keep [noissue] and reviewer keeps an eye whether an opened issue is needed.<br></div><div dir="ltr"><br>--------<br>Regards,<br><br>Ina Panova<br>Senior Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 6, 2019 at 6:51 PM Daniel Alley <<a href="mailto:dalley@redhat.com">dalley@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Agreed, I would also rather keep [noissue]. That is a good example of when it is useful. We can and should pay more attention to when it's being used in the PR review process, though.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 6, 2019 at 12:26 PM Tatiana Tereshchenko <<a href="mailto:ttereshc@redhat.com" target="_blank">ttereshc@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'm leaning towards keeping [noissue] and have it a responsibility of PR reviewer/merger to evaluate if it's a proper use or an issue is needed.</div><div><br></div><div>Alternatively, can we block a merge of PR if there is no issue? at github level, not in travis? so tests run but you can only merge it "using your admin privileges" by pressing a very red button :)</div><div>One good case for noissue is all the release PRs I think. So if we let tests run regardless of the issue specified in the commit and only block merge, it's probably fine to press the red button for the release PRs only.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 6, 2019 at 3:55 PM Matthias Dellweg <<a href="mailto:dellweg@atix.de" target="_blank">dellweg@atix.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Being a regular user of noissue, i think it is ok to keep it, if the<br>
reviewer can tell the contributer at some time that the change is<br>
effecting something worth noting in the changelog. Sometimes, what<br>
starts as a very small change evolves into something bigger.<br>
Sometimes you might even want to show some code without knowing whether<br>
there is an issue at all. Removing this loophole would prevent those<br>
code paths from ever running in the ci.<br>
<br>
I'd vote for not removing the [noissue] functionality, but instead keep<br>
an open eye on it's usage, and in case request that a ticket be opened.<br>
<br>
On Wed, 6 Nov 2019 08:52:14 -0500<br>
David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br>
<br>
> When we added commit validation to our CI, we created a loophole that<br>
> would allow small changes like typo fixes to not have a redmine issue<br>
> or changelog entry. By having '[noissue]' in the commit message,<br>
> users could bypass our commit requirements. However, this loophole is<br>
> not being used as intended--it's being used for all sorts of changes<br>
> from new features to bug fixes.<br>
> <br>
> This is going to be a major problem for users and plugin writers when<br>
> we release 3.0 and they start to upgrade from release to release.<br>
> These [noissue] changes won't being reflected in our changelog which<br>
> invalidates the motivation behind having a changelog.<br>
> <br>
> My first inkling is to remove the '[noissue]' functionality. Other<br>
> projects like Katello and foreman already do this. If you don't want<br>
> your change reflected in the changelog, you should be creating .misc<br>
> entries for these changes in the CHANGES folder. The downside to this<br>
> is every change will require a changelog and issue, and this creates<br>
> extra steps for devs and contributors.<br>
> <br>
> Another option is to make our check smarter by incorporating some<br>
> other condition(s) or metric(s). For example, perhaps we could allow<br>
> [noissue] changes only to certain directories like our tests<br>
> directory. The problem here is getting the parameters right. What<br>
> sorts of changes changes should we allow to be [noissue] ones? I've<br>
> thought about this a bit and couldn't think of a good set of criteria.<br>
> <br>
> Thoughts?<br>
> <br>
> David<br>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>