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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
> 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
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
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,
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
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
20 matches
Mail list logo
