<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Thierry,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 4 juin 2019 à 08:36, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="mailto:eric.ernst@intel.com" target="_blank">eric.ernst@intel.com</a> wrote:<br>
> Kata-folk,<br>
> <br>
> A couple months ago I enabled stale bot [1] in the packaging repository,<br>
> [2], and with the creation of the .github repository under<br>
> kata-containers by James Hunt, this same configuration may be used with all the<br>
> repositories.<br>
> <br>
> James and I were planning on enabling the stale-bot for the rest of the<br>
> repositories, based on this.  Any concerns?  Thierry, this look okay to<br>
> you? Any license concerns, [3]?<br>
<br>
Re-posting my comment on the issue:<br>
<br>
I don't see any issue with using Probot apps, except I guess that it <br>
locks us in even deeper into GitHub (but that ship has sailed already).<br></blockquote><div><span class="gmail_default" style="font-size:small">Yes and no.</span> <span class="gmail_default" style="font-size:small">"Yes", because we'd be using a service which we believe is hosted on GitHub. But "no" because as that tool uses a YAML configuration file, we're encoding our process in a program ("infrastructure as code"). In fact, there are quite a few other examples of infrastructure as code across the repos (CODEOWNERS, versions.yaml, .travis.yml, Jenkins XML config, labels.yaml). Hence, although we may be using GitHub today and considering using another service to run on GitHub servers, it would in theory be possible to switch to a.n.other git hosting site as the Kata project owns its infrastructure configuration in a form that can be manipulated to conform to the requirements of alternative git hosting sites infrastructure configuration.</span></div><div><span class="gmail_default" style="font-size:small"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The only potential issue I see is in the social function of the Stale <br>
app. In previous projects I was involved in (including Ubuntu and <br>
OpenStack), whether or not to autoclose issues has always been a hot topic!<br>
<br>
While it is convenient for developers (and reduce the need to manually <br>
review each), autoclosing generally appears as a user-hostile move, and <br>
may result in overlooking real bugs. It's generally justified when the <br>
rate of issue creation spirals out of control, but I'm not sure Kata has <br>
hit that point yet?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">This is a valid concern and I can see it being a potentially emotive topic. To allay some fears though (maybe ;), here is the behaviour that stalebot would provide based on our config [1].</div><br></div><div><div class="gmail_default" style="font-size:small"># Issues</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- If an issue has not been "updated" in 60 days, add a comment to the issue and add the "stale" label.</div><div class="gmail_default" style="font-size:small">- If an issue has not been updated after 67 days, close it.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"># PRs</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><div class="gmail_default">- If a PR has not been "updated" in 30 days, add a comment to the issue and add the "stale" label.</div><div class="gmail_default">- If a PR has not been updated after 37 days, close it.</div><div class="gmail_default"><br></div><div class="gmail_default"># Analysis</div><div class="gmail_default"><br></div><div class="gmail_default">67 days and 37 days should allow for even the most relaxing holiday (maybe even a sabbatical or two ;) I'm not sure of the precise behaviour here, but in the worst case scenario, if the author adds a quick "sorry - still looking at this" comment, the clock resets so they get another (x+7) days to continue working. But in fact, it might be the "best case scenario" whereby if *anyone* adds a comment, the clock resets. In that scenario, technically none of the PRs should ever be auto-closed since the Rota Team should be pinging "slow" PRs regularly which would be continually resetting the clock. However, I grant that this isn't happening today for issues so they may end up expiring.</div><div class="gmail_default"><br></div><div class="gmail_default">It's also worth stating that even if an issue/PR is "closed", that's simply a state - the issue/PR can still be re-opened by anyone. Plus, you can still search for and comment on them as before of course. Of course, that argument can be inverted to be "so why bother closing them? Why not just ignore the stale ones in reports?"</div><div class="gmail_default"><br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Note that there is no issue with marking issues with a "stale" tag,</blockquote><div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">Agreed.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">it's <br>
the action of having a bot closing issues automatically that is <br>
debatable...</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">OK. so although I think we are providing enough time for users to respond, how about we change the stalebot config so that we don't actually close the issues - we simpy add the "stale" tag? [2]<br></div><div class="gmail_default"><br></div><div class="gmail_default">We can then assess the "rate of staleness" to see if we need to turn on the auto-close feature.<br></div><div class="gmail_default"><br></div><div class="gmail_default">And *iff* we do end up having to enable the auto-close feature, it would probably make sense to do the following (at that point):</div><div class="gmail_default"><br></div><div class="gmail_default">- Change pulls.daysUntilStale from 30 to 15.</div><div class="gmail_default">- Change issues.daysUntilStale from 60 to 45.<br></div><div class="gmail_default">- Change daysUntilClose from 7 to 22.</div><div class="gmail_default"><br></div><div class="gmail_default">That wouldn't change _when_ the close occurred, but would give user more notice as we'd be warning them "about halfway" in terms of days before we close them.<br></div><div class="gmail_default"><br></div><div class="gmail_default"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and at least worth a discussion here before proceeding.<br></blockquote><div><br class="gmail-Apple-interchange-newline"></div></div><div class="gmail_default">Yep - I'm not going to be able to attend, but this seems like a good topic for the Architecture Committee call later today.<br></div><div class="gmail_default"> <br></div><div class="gmail_default"><div class="gmail_default">Cheers,</div><div class="gmail_default"><br></div><div class="gmail_default">James</div><div class="gmail_default"><br></div><div class="gmail_default">[1] - <a href="https://github.com/kata-containers/.github/blob/master/.github/stale.yml#L10..L13">https://github.com/kata-containers/.github/blob/master/.github/stale.yml</a></div></div><div class="gmail_default" style="font-size:small">[2] - <a href="https://github.com/kata-containers/.github/blob/master/.github/stale.yml#L10..L13">https://github.com/kata-containers/.github/blob/master/.github/stale.yml#L10..L13</a></div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Thierry Carrez (ttx)<br>
<br>
_______________________________________________<br>
kata-dev mailing list<br>
<a href="mailto:kata-dev@lists.katacontainers.io" target="_blank">kata-dev@lists.katacontainers.io</a><br>
<a href="http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev" rel="noreferrer" target="_blank">http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font color="#888888"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">James<br>---</span></span></font></div><div dir="ltr"><a href="https://katacontainers.io/" style="color:rgb(17,85,204);font-family:monospace,monospace" target="_blank">https://katacontainers.io/</a><span style="color:rgb(136,136,136);font-family:monospace,monospace"> | <a href="https://github.com/clearcontainers" target="_blank">https://github.com/kata-containers</a></span><font color="#888888"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><br></span></span></font></div><div dir="ltr"><font color="#888888"><font face="monospace, monospace">Open Source Technology Center</font><br><font face="monospace, monospace">Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.</font></font><br></div></div></div></div></div></div></div></div></div></div></div></div>