Re: stale MR triage
El dimecres, 23 de setembre de 2020, a les 11:27:18 CEST, Harald Sitter va escriure: > On 19.09.20 02:18, Albert Astals Cid wrote: > > Not really, the thing is, for Okular i knew that all things that were old > > didn't need my attention, it was either on the patch author to come back > > and fix something or someone else should be the one reviewing, so just > > looking at the last updated MRs gave me an overview if something had > > changed that needed my attention, now suddenly that's not true anymore. > > Hm. I'm thinking we maybe should filter out okular from the triage in > general then. In the scenarios you describe I'd expect the triage team > to most likely write ping comments of some sort, so the MRs would jump > to the top of the list even without the help of gitlab backreference. > > Thoughts? That doesn't make much sense to me. I guess i'll just have to adapt my workflow. Cheers, Albert > > HS >
Re: stale MR triage
On 19.09.20 02:18, Albert Astals Cid wrote: > Not really, the thing is, for Okular i knew that all things that were old > didn't need my attention, it was either on the patch author to come back and > fix something or someone else should be the one reviewing, so just looking at > the last updated MRs gave me an overview if something had changed that needed > my attention, now suddenly that's not true anymore. Hm. I'm thinking we maybe should filter out okular from the triage in general then. In the scenarios you describe I'd expect the triage team to most likely write ping comments of some sort, so the MRs would jump to the top of the list even without the help of gitlab backreference. Thoughts? HS
Re: stale MR triage
El divendres, 18 de setembre de 2020, a les 13:32:23 CEST, Harald Sitter va escriure: > On Fri, Sep 18, 2020 at 12:36 AM Albert Astals Cid 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? Yes, sorry. > 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? Not really, the thing is, for Okular i knew that all things that were old didn't need my attention, it was either on the patch author to come back and fix something or someone else should be the one reviewing, so just looking at the last updated MRs gave me an overview if something had changed that needed my attention, now suddenly that's not true anymore. Cheers, Albert > > HS >
Re: stale MR triage
On Fri, Sep 18, 2020 at 3:09 AM Ben Cooksley wrote: > > On Fri, 18 Sep 2020, 2:58 am Harald Sitter, wrote: >> >> Griaß eich! > > > Hi Harald, > >> >> 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. > > > Please note that from my reading of the code this would also trigger for > people's personal projects as well? It only lists !personal projects: https://invent.kde.org/sitter/triage/-/blob/master/plugin.rb#L34 takes care fo that. > I assume the token it currently uses is your personal one? Yep, Bhushan was thinking we should use a bot account, and I agree. >> >> 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? >> >> [1] https://invent.kde.org/sitter/triage/-/pipelines >> [2] https://gitlab.com/gitlab-org/gitlab-triage >> [3] https://invent.kde.org/sitter/demo/-/issues/2 (feel free to deal >> with items on this list already) >> >> HS > > > Cheers, > Ben
Re: stale MR triage
On Fri, Sep 18, 2020 at 12:36 AM Albert Astals Cid 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
Re: stale MR triage
On Fri, 18 Sep 2020, 2:58 am Harald Sitter, wrote: > Griaß eich! > Hi Harald, > 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. > Please note that from my reading of the code this would also trigger for people's personal projects as well? I assume the token it currently uses is your personal one? > 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? > > [1] https://invent.kde.org/sitter/triage/-/pipelines > [2] https://gitlab.com/gitlab-org/gitlab-triage > [3] https://invent.kde.org/sitter/demo/-/issues/2 (feel free to deal > with items on this list already) > > HS > Cheers, Ben >
Re: stale MR triage
El divendres, 18 de setembre de 2020, a les 0:36:04 CEST, Albert Astals Cid va escriure: > 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. > > That makes me very unhappy and more unproductive. > > 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? s/next month/next week > > How can we fix that? > > Cheers, > Albert > > > > > [1] https://invent.kde.org/sitter/triage/-/pipelines > > [2] https://gitlab.com/gitlab-org/gitlab-triage > > [3] https://invent.kde.org/sitter/demo/-/issues/2 (feel free to deal > > with items on this list already) > > > > HS > > > > > > >
Re: stale MR triage
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. That makes me very unhappy and more unproductive. 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? How can we fix that? Cheers, Albert > > [1] https://invent.kde.org/sitter/triage/-/pipelines > [2] https://gitlab.com/gitlab-org/gitlab-triage > [3] https://invent.kde.org/sitter/demo/-/issues/2 (feel free to deal > with items on this list already) > > HS >
