Hi Rajani, If we truly “merge” PRs, which I think we should do (instead of applying a patch) then those will be in state “Merged” (purple) versus “Closed” (red).
Regards, Remi On 17 Aug 2015, at 18:56, Rajani Karuturi <raj...@apache.org<mailto:raj...@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.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> wrote: +1 Sounds reasonable On Mon, Aug 17, 2015 at 8:25 AM, Remi Bergsma <rberg...@schubergphilis.com<mailto:rberg...@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.tutkow...@solidfire.com<mailto:mike.tutkow...@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
