On Fri, Sep 18, 2020 at 12:36 AM Albert Astals Cid <aa...@kde.org> wrote: > > El dijous, 17 de setembre de 2020, a les 16:57:32 CEST, Harald Sitter va > escriure: > > Griaß eich! > > > > In the KF6 BOF we were chatting about merge requests not being nearly > > as actively watched because people didn't necessarily subscribe to all > > projects. While that is a solvable problem by asking people to kindly > > subscribe, it got us thinking that we should have a way to deal with > > stale MRs in general. For all projects. > > > > So.... here's the proposal: > > > > We'll setup a new triage project (prototype at [1]; going to move) > > that project runs a pipeline once a week that runs the existing > > gitlab-triage tool [1] to collect all MRs that haven't received an > > update for 2 weeks. The MRs are then dumped into an issue on the > > triage project (ex at [2]). Anyone who is willing to help out with cat > > herding can subscribe to that project and gets notified of these > > auto-generated issues. We can then walk through the list of stales to > > work out a solution for getting them moving (assign a helpful > > reviewer, ping, review ourselves). > > > > Any further thoughts? > > My default "sort MR by age" view in Okular is now unusable since there's > suddenly a bunch of MRs that are now 2 days old instead of 9 months old.
To clarify: that's "sort by last update", not age, right? The creation date of an MR shouldn't change, the update date however does. > That makes me very unhappy and more unproductive. I'm sorry, I hadn't thought of the possibility that merely mentioning an MR counts as an update to the MR. > And i guess it basically breaks your code since next month those MRs are not > without updates for 2 weeks because you just linked to them last week? It's not the biggest concern, ideally every week all stale MRs should be dealt with somehow anyway, so there'd be some update which would make them not stale. Should they become stale again the delay increases of course, but they'll appear again after 4 weeks from the original stale mention. > How can we fix that? I fear that'd need taking up with gitlab. The reason they become updated is because linking anywhere on gitlab to any MR introduces a backreference "so and so mentioned this MR in issue #3" which as we've found out is considered an update to the MR thus messing with the last-update sorting. It really is not the most reasonable behavior IMHO. Would sorting by creation instead work for you? HS
