cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Bergsma <RBerg...@schubergphilis.com>
Subject Re: [PROPOSAL] Closing PRs older than 1 month and without activity
Date Tue, 18 Aug 2015 14:15:09 GMT
Hi all,

This PR includes the ones we can close now:
https://github.com/apache/cloudstack/pull/706

Any LGTM’s so we can merge it?

Thanks,
Remi


On 17 Aug 2015, at 18:56, Rajani Karuturi <rajani@apache.org<mailto:rajani@apache.org>>
wrote:

+1 for auto closing.
I also agree with Boris that we need to distinguish discarded vs. Merged
prs.


On Mon, Aug 17, 2015 at 21:51 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com>> wrote:

+1 Sounds reasonable

On Mon, Aug 17, 2015 at 8:25 AM, Remi Bergsma <RBergsma@schubergphilis.com<mailto:RBergsma@schubergphilis.com>
<javascript:;>>
wrote:

Hi all,

There are several PRs that are quite old. They haven't been updated by
their author for over a month and there was no response to comments made.

As a RM, I want to maintain an as-short-as-possible list of PRs that is
actively worked on. It is perfectly fine if a PR is open for a longer
time,
as long as it is actively maintained (or has a comment that explains why
there is a delay). Long lists of open PRs don't give the impression we
actively work on them and might keep people from contributing.

Proposal:
Let's close PRs where the author did not respond for over a month.

How?
For now, I'll manually select the PRs that I propose to close. Next, I
make a PR with an empty commit that closes the PRs by triggering asfbot
(as
we cannot otherwise close PRs due to it being read-only for committers).
By
using a PR, it should be visible which PRs will get closed (after 2x LGTM
and no -1). I’ll send an example PR with link to this thread after I've
sent this e-mail.

Work lost?
The work done in a PR is not lost by closing the PR! If someone wants to
take over, this is how you can merge the work in a new branch (keeping
author and commit hashes the same) and add more commits on top of it. You
can then send it as a new PR.

Example:
 prId=12345
 git fetch origin pull/${prId}/head:pr/${prId}
 git merge --no-ff --log -m "Merging PR ${prId} and continuing the work"
pr/${prId}
 git commit --amend -s --allow-empty-message -m ''


Please let me know what you think: +1 or -1?

If -1, what should we do instead?

Regards,
Remi




--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com> <javascript:;>
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*



--
-
Sent from Windows Phone
~Rajani

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message