Le mar. 7 mars 2023 à 00:15, AnnoyingRains <annoyingra...@gmail.com> a écrit :
> > We should never close a MR automatically. Only a maintainer of a project > or the author itself should close a MR. > > I agree with not closing MRs automatically. As I stated in my original > message, we are no longer planning on doing that, it's not helpful and > is only destructive. > The decision to close an MR will be left with the specific project's > maintainers and the person who opened the MR. > > I would argue we should allow some degree of automated closing. Maintainers' time is precious, requiring maintainers to follow up every opened MRs in addition to the bugs and their own dev work is excessive. Contributors should be warned and have a say, but when they don't react, what to do then ? That's something that happens for dolphin or Kio, cases I know. Plus the longer the stale guests the more bit-rot the code gets. Every MRs gets either merged given enough time, or abandoned by its author(s). We can't expect every contributor to finish their MR and especially months or years later. Some will, some won't. I guess projects could have different needs, but it seems to me a large auto-close threshold of 18 or 24 months or so would hardly do any harm. We could use a "stale" label for MR to allow maintainers to see the script's results. And even a "closing-soon" label, for MR not-update in the last 12 months. > > The decision if a MR should be closed or not is often depending on a > context (e.g. a MR required another MR to be merged first > > and it is taking more time than expected, the author is busy with other > things but will eventually come back to it, ...) > > and a script is unable to see this. > > I would also argue that humans that are not a maintainer of that > specific project should not close an MR for similar reasons. There is > a lot here that the gardening team would need to know about every > project > > > for GCompris, we don't have a lot of MR and even if some are old, we > still plan to take over them at some point (we know which ones are > unmaintained) so I think it's preferable to not add messages. > > We can exclude Gcompris if you feel it is needed, but I am unsure how > labeling MRs as stale and reminding authors wouldn't be preferable. > > > but this should probably be done manually > > We are planning on doing this manually until all of the issues have > been ironed out perfectly and we know a foolproof way to ensure > nothing is ever poked that shouldn't be, which may never happen. > We will open another discussion before automating anything, due to the > potential disaster a bug could cause. > > > "Hi, I really like this work, do you intent to continue working > > on it or can I take over" than a generic message that feels fake. > > This is great, but not exactly what this inititive is about. > This is more for reminding people that the MR exists (even had one > case of "oh! I forgot I made this MR" in my small scale test!), and > labeling MRs so that contributors feel more free to request taking > over the project. > Basically, we cannot really take over every stale MR in the entirety of > KDE. > > - Kye Potter, KDE Gardening > > > On Tue, Mar 7, 2023 at 9:39 AM Albert Astals Cid <aa...@kde.org> wrote: > > > > El dilluns, 6 de març de 2023, a les 15:18:42 (CET), Carl Schwan va > escriure: > > > Hi, > > > > > > We should never close a MR automatically. Only a maintainer of a > project > > > or the author itself should close a MR. The decision if a MR should be > > > closed or not is often depending on a context (e.g. a MR required > another > > > MR to be merged first and it is taking more time than expected, the > > > author is busy with other things but will eventually come back to it, > ...) > > > and a script is unable to see this. > > > > > > I do not mind poking people semi-regularly (every 6 months or so), but > again > > > this should probably be done manually and with a small personalized > message > > > for example: "Hi, I really like this work, do you intent to continue > > > working on it or can I take over" than a generic message that feels > fake. > > > > > > I really hate communicating with robots instead of with humans and I > really > > > see the trends of trying to automatize all our interaction with dumb > robots > > > and chat bots in our society really worrying. > > > > > > If we want to automatize, we should instead try to list the stale MRs > and > > > maybe send the list to the mailing list once a month so that people are > > > reminded about them and take a look at which one they may be able to > unlock. > > > > We already have that, they get posted to > > https://invent.kde.org/teams/gardening/gitlab/-/issues > > weekly. > This listing is great, could we add a label "stale" to the MR concerned so that's explicit for maintainers. -- Méven
