Jenkins Core pull-requests management

35 views
Skip to first unread message

Adrien Lecharpentier

unread,
Mar 22, 2022, 12:07:15 PM3/22/22
to Jenkins Developers
Hello everyone,

I've spent some time lately on looking at the pull-requests on jenkinsci/jenkins repository. For some old, inactive pull-requests I've pinged the authors and for some, added the proposed-for-close label.

However, the label description nor any prior discussion on the mailing-list are mentioning our policy about this (proposed-for-close) label. And I'd like to offer one: I'd like, as for the ready-for-merge label, to introduce a period of time, after which with no response from the author, we close the pull-request. I was thinking about 72 or 96hr.

This might seem a bit harsh, but my idea is to try to keep the pull-requests list healthy. And when we have no consensus on the PR or no response from the authors, it's healthier to close the pull-request. The work done is not lost, the PR can be reopen later when the author is more available to attend to it.

Also, in case the authors respond, we can simply put the label stalled (for others to take over the PR). We could also put the PR back into draft, but all members have enough permission to do that on others pull-requests, but we could use the work-in-progress. Of course, after another period of time, with no more activities, we should close the PR anyway.

Also, there is no mention of those labels, what they means and how we use it on our contribution guide [1]. Should we add a mention of those label on it?

-- Adrien

Jeff

unread,
Mar 22, 2022, 12:27:34 PM3/22/22
to jenkin...@googlegroups.com
This seems reasonable to me. After some period of time (months? years?) the PR is unlikely to be merged, so why keep it open if it's truly stale?


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKwJSvwTnxuwe1WZzs3eSJBgq783fMm8hkQ_-%3DFHS1u0%2B7GUAw%40mail.gmail.com.

Alex

unread,
Mar 22, 2022, 1:17:14 PM3/22/22
to Jenkins Developers
Heyo,

that is an interesting proposal. Currently, there are quite a lot of stale pull requests, whether labeled with a stale-like label or not, which's state is unclear how to proceed with them. 
I think working with labels is easier, instead of converting the PRs into drafts, because a stale draft PR hardly differs from a draft that is work in progress. A label can show that state well without the need to read over the PR again.

> Also, there is no mention of those labels, what they means and how we use it on our contribution guide [1]. Should we add a mention of those label on it?
There's an overview of all labels available on https://github.com/jenkinsci/jenkins/labels. We could fill in missing descriptions and overhaul existing ones, if needed. The contribution guide could link to the former URL where you can browse PRs with specific labels right away.

~ Alex

Olivier Lamy

unread,
Mar 22, 2022, 6:41:28 PM3/22/22
to jenkin...@googlegroups.com
On Wed, 23 Mar 2022 at 02:07, Adrien Lecharpentier <adrien.lec...@gmail.com> wrote:
Hello everyone,

I've spent some time lately on looking at the pull-requests on jenkinsci/jenkins repository. For some old, inactive pull-requests I've pinged the authors and for some, added the proposed-for-close label.

However, the label description nor any prior discussion on the mailing-list are mentioning our policy about this (proposed-for-close) label. And I'd like to offer one: I'd like, as for the ready-for-merge label, to introduce a period of time, after which with no response from the author, we close the pull-request. I was thinking about 72 or 96hr.

Definitely sounds good to clean up some stale/dead PRs but I find 96h a bit too short. (people can be off for few days/weeks and 1 or 2 weeks for 2 yo old PR will not hurt more)
I have implemented something similar in some plugins using stale action see configuration here https://github.com/jenkinsci/maven-plugin/blob/master/.github/workflows/stale.yml  (tool here: https://github.com/actions/stale)
with this configuration PRs 365 days old are marked stale then after 30 days they are closed.

 

This might seem a bit harsh, but my idea is to try to keep the pull-requests list healthy. And when we have no consensus on the PR or no response from the authors, it's healthier to close the pull-request. The work done is not lost, the PR can be reopen later when the author is more available to attend to it.

Also, in case the authors respond, we can simply put the label stalled (for others to take over the PR). We could also put the PR back into draft, but all members have enough permission to do that on others pull-requests, but we could use the work-in-progress. Of course, after another period of time, with no more activities, we should close the PR anyway.

Also, there is no mention of those labels, what they means and how we use it on our contribution guide [1]. Should we add a mention of those label on it?

-- Adrien

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKwJSvwTnxuwe1WZzs3eSJBgq783fMm8hkQ_-%3DFHS1u0%2B7GUAw%40mail.gmail.com.

Adrien Lecharpentier

unread,
Mar 23, 2022, 4:43:37 AM3/23/22
to Jenkins Developers
Alex, I agree that we have the list of labels but even for `ready-for-merge`, we haven't document there what we tend to say when we put the label: the pr should be merge within 24hr (with no negative feedback). It is important that we have a clear guideline, like

>  * If you do not get feedback after 3 days, feel free to ping `@jenkinsci/core-pr-reviewers` in the comments.

I think it's important to be clear, for the community and all contribution that everyone opening a PR should get a review and comments. But also that, to limit the time lost by anyone, when a PR is no where close to be merge, there is no consensus on it's content, there are concerns about its quality / justifications, we should close it, in a timely matter.

Again, I think this is to show respect to all contributors, to show that contributions are not going into a void, that we care about them. And I feel like we are lacking clarity about it for the moment.

Le mar. 22 mars 2022 à 23:41, Olivier Lamy <olive...@gmail.com> a écrit :


On Wed, 23 Mar 2022 at 02:07, Adrien Lecharpentier <adrien.lec...@gmail.com> wrote:
Hello everyone,

I've spent some time lately on looking at the pull-requests on jenkinsci/jenkins repository. For some old, inactive pull-requests I've pinged the authors and for some, added the proposed-for-close label.

However, the label description nor any prior discussion on the mailing-list are mentioning our policy about this (proposed-for-close) label. And I'd like to offer one: I'd like, as for the ready-for-merge label, to introduce a period of time, after which with no response from the author, we close the pull-request. I was thinking about 72 or 96hr.

Definitely sounds good to clean up some stale/dead PRs but I find 96h a bit too short. (people can be off for few days/weeks and 1 or 2 weeks for 2 yo old PR will not hurt more)
I have implemented something similar in some plugins using stale action see configuration here https://github.com/jenkinsci/maven-plugin/blob/master/.github/workflows/stale.yml  (tool here: https://github.com/actions/stale)
with this configuration PRs 365 days old are marked stale then after 30 days they are closed.
 
A PR can always be reopen, the discussions and work put in it is not lost. 96hr with no activities seems long enough. It's not 96hr after the last message / commit, but 96hr after the label *with a message* is applied to the PR. We could definitively say that for PR with no activities in the last month, or less if some review comment were not addressed, we put a message and the label on the PR.
 
 This might seem a bit harsh, but my idea is to try to keep the pull-requests list healthy. And when we have no consensus on the PR or no response from the authors, it's healthier to close the pull-request. The work done is not lost, the PR can be reopen later when the author is more available to attend to it.

Also, in case the authors respond, we can simply put the label stalled (for others to take over the PR). We could also put the PR back into draft, but all members have enough permission to do that on others pull-requests, but we could use the work-in-progress. Of course, after another period of time, with no more activities, we should close the PR anyway.

Also, there is no mention of those labels, what they means and how we use it on our contribution guide [1]. Should we add a mention of those label on it?

-- Adrien

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKwJSvwTnxuwe1WZzs3eSJBgq783fMm8hkQ_-%3DFHS1u0%2B7GUAw%40mail.gmail.com.


--

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

Adrien Lecharpentier

unread,
Mar 23, 2022, 5:39:39 AM3/23/22
to Jenkins Developers
For everyone, to give data about why I started this discussion:
 - we have 66 opens pull-requests, 5 of them are marked as ready-for-merge
 - 10 out of 61 pull-requests are labeled proposed-for-close
 - of the 10 oldest open pull-requests, 7 are labels proposed-for-close
 - the 17 oldest open pull-requests were all created in 2020.

Some of those old ones have been reviewed, approved but yet, because they are old, now have merge conflicts. As some authors change focus with time, which is perfectly normal to me, at some point we don't get any activities, leading the pull-requests to be stalled.
I think having a clear closing policy will also help us prevent this situation.

Adrien Lecharpentier

unread,
Mar 28, 2022, 10:00:53 AM3/28/22
to Jenkins Developers
Hello everyone,

I created https://github.com/jenkinsci/jenkins/pull/6413 to move this subject forward.
Reply all
Reply to author
Forward
0 new messages