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 o
On Freitag, 10. März 2023 20:55:00 CET Ben Cooksley wrote:
> On Sat, Mar 11, 2023 at 3:19 AM David Hurka 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
On Sat, Mar 11, 2023 at 3:19 AM David Hurka 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 ru
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 i
On donderdag 9 maart 2023 09:40:47 CET Méven wrote:
> Maintainers' time is precious, requiring maintainers to follow up every
> opened MRs in addition to the bugs and their own dev work is excessive.
That is true, and it's why I have asked for Krita to be excluded from
gardening. Every gardening
Le mar. 7 mars 2023 à 00:15, AnnoyingRains 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
KDiff3 is in a similar position to GCompris and would not at this benefit from
auto closing or extra messaging on MR's
Mar 6, 2023 3:29:12 PM Johnny Jazeix :
> Hi,
>
> 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 whi
Le mar. 7 mars 2023 à 00:15, AnnoyingRains 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
> 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 c
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 requi
Hi,
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.
In a general manner, as said by Carl, MR should not be closed automatically.
Cheers,
Johnny
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 i
For a short amount of time now, there have been some small-scale
trials of replying to old MRs with a reminder, and suggesting that the
author closes the MR if it is either no longer needed or if it needs
more work and the author does not have time for it.
This has appeared to have a positive impa
13 matches
Mail list logo
