MR Gardening - A discussion, please leave your input!

[AnnoyingRains]

I believe this discussion can now be closed.

I have just added Gcompris and KDiff3 to the Exclusions list on the 
https://community.kde.org/Gardening page

KDE Gardening will now properly start labeling stale MRs as 'Gardening: 
Stale' and posting a reminder message when the MR reaches 30 days of 
zero activity.

KDE Gardening will NOT close any MRs, although the option of closing the 
MR is offered in the message.

"[...] If this merge request isn’t needed anymore, or if you aren’t 
willing to work on it, you may close it.

Note that KDE Gardening will **NOT** close this MR, only the projects 
maintainers or the author of an MR can close it. [...]"


If you would like to add your project to the list of exclusions, please 
send an email to gardening at kde.org.


Thanks for your feedback,

- Kye Potter, KDE Gardening.


On 11/03/2023 5:01 pm, Thomas Baumgart wrote:
> On Freitag, 10. März 2023 20:55:00 CET Ben Cooksley wrote:
>
>> On Sat, Mar 11, 2023 at 3:19 AM David Hurka <david.hurka at mailbox.org> wrote:
>>
>>> On Thursday, March 9, 2023 9:40:47 AM CET Méven wrote:
>>>> 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.
>>> Is there a rule that all open merge requests need care?
>>> I would expect that it is enough to label an open merge request as “stale”.
>>>
>>> Merge requests are usually closed because they are bad.
>>> Stale merge requests are probably good, otherwise they would have been
>>> closed
>>> intentionally.
>>>
>> I recall in the last few months someone mentioning a MR in #kde-devel that
>> had been approved and just never merged, and had been sitting like that for
>> months.
>> All it took to get merged was a reminder by way of comment on the MR to get
>> it merged as the original author of the change was no longer around.
>>
>> So yes, there is definitely value in reminders and caring for those MRs.
>>
>> I guess the difference here is between higher activity projects - whose MRs
>> are likely to be more well looked after - and those with lower activity.
>> Projects with lower activity tend to involve developers who look after many
>> different projects, and will therefore benefit from reminders. Those with
>> higher activity are much less likely to see value from it.
>>
>> Closing of MRs though is something that should only be done after review by
>> the developers who run the project.
> Maybe in a semi-automated way such that the developer can mark the MR in
> a specific way and which closes it after a grace period when there is no
> more activity.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20230315/1eb66a6e/attachment.sig>