Open Stack

Hi Thierry,

Le mar. 4 juin 2019 à 08:36, Thierry Carrez <thierry at openstack.org> a
écrit :

> eric.ernst at intel.com wrote:
> > Kata-folk,
> >
> > A couple months ago I enabled stale bot [1] in the packaging repository,
> > [2], and with the creation of the .github repository under
> > kata-containers by James Hunt, this same configuration may be used with
> all the
> > repositories.
> >
> > James and I were planning on enabling the stale-bot for the rest of the
> > repositories, based on this.  Any concerns?  Thierry, this look okay to
> > you? Any license concerns, [3]?
>
> Re-posting my comment on the issue:
>
> I don't see any issue with using Probot apps, except I guess that it
> locks us in even deeper into GitHub (but that ship has sailed already).
>
Yes and no. "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.


> The only potential issue I see is in the social function of the Stale
> app. In previous projects I was involved in (including Ubuntu and
> OpenStack), whether or not to autoclose issues has always been a hot topic!
>
> While it is convenient for developers (and reduce the need to manually
> review each), autoclosing generally appears as a user-hostile move, and
> may result in overlooking real bugs. It's generally justified when the
> rate of issue creation spirals out of control, but I'm not sure Kata has
> hit that point yet?
>

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].

# Issues

- If an issue has not been "updated" in 60 days, add a comment to the issue
and add the "stale" label.
- If an issue has not been updated after 67 days, close it.

# PRs

- If a PR has not been "updated" in 30 days, add a comment to the issue and
add the "stale" label.
- If a PR has not been updated after 37 days, close it.

# Analysis

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.

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?"


> Note that there is no issue with marking issues with a "stale" tag,

Agreed.


> it's
> the action of having a bot closing issues automatically that is
> debatable...


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]

We can then assess the "rate of staleness" to see if we need to turn on the
auto-close feature.

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):

- Change pulls.daysUntilStale from 30 to 15.
- Change issues.daysUntilStale from 60 to 45.
- Change daysUntilClose from 7 to 22.

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.

and at least worth a discussion here before proceeding.
>

Yep - I'm not going to be able to attend, but this seems like a good topic
for the Architecture Committee call later today.

Cheers,

James

[1] -
https://github.com/kata-containers/.github/blob/master/.github/stale.yml
<https://github.com/kata-containers/.github/blob/master/.github/stale.yml#L10..L13>
[2] -
https://github.com/kata-containers/.github/blob/master/.github/stale.yml#L10..L13


> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>


-- 
James
---
https://katacontainers.io/ | https://github.com/kata-containers
<https://github.com/clearcontainers>
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3
1RJ.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20190604/c2e1e619/attachment-0001.html>