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

eric.ernst@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...

-- Thierry Carrez (ttx)

_______________________________________________ kata-dev mailing list kata-dev@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.