SubmittingPatches: abandoning a series
PATCH 1/1 SubmittingPatches: abandoning a series
The document describes an idealized life cycle for a patch series, where an author scratches their itch, improves the patch(es) with help from fellow reviewers, and iterate until their work becomes a part of Git.
But sometimes a topic may have to be abandoned or retracted, with an option to later resurrect it when they can, and it is much better than leaving a topic in limbo. Clearly state that we encourage contributors to explicitly retract their topic that did not succeed.
--- Documentation/SubmittingPatches | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
Documentation/SubmittingPatches +15 -0
@@ -95,6 +95,21 @@ input and avoids unnecessary churn from many rapid iterations. top, it gets merged to the 'master' branch and waits to become part of the next major release. +But sometimes things do not work as planned. + +. A discussion on the list might convince you that your changes are + not such a good idea, in which case you are expected to explicitly + retract the topic, to releave the maintainer from having to worry + about it. + +. You may have to stop pursuing the topic due to various reasons like + lack of time, other commitments, shifting priorities, etc. It is a + friendly thing to do to tell the list in such a case, so that others + interested in the topic can take over the topic and continue. When + there is no taker, the maintainer may have to discard the topic, but + anybody can resurrect the topic later when they (including you) can + spend more time on it. + In the following sections, many techniques and conventions are listed to help your patches get reviewed effectively in such a life cycle.
PATCH v2 1/1 SubmittingPatches: document how to retract a topic
While this document outlines an idealized lifecycle where an author develops a patch, refines it with reviewer feedback, and successfully merges it into Git, reality is rarely so seamless.
Sometimes, a topic must be abandoned. Doing so explicitly is far better than leaving it in limbo, especially since topics can always be resurrected later.
Clearly state that we encourage contributors to retract any topic that does not pan out.
---
* Added the third bullet that talks about when and how a topic becomes stalled and discarded.
Documentation/SubmittingPatches | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
Documentation/SubmittingPatches +14 -0
@@ -123,6 +123,20 @@ of review. top, it gets merged to the 'master' branch and waits to become part of the next major release. +But sometimes things do not work as planned: + +. If a mailing list discussion convinces you that your changes aren't + ideal, please explicitly retract the topic to save the maintainer + time and effort. + +. If you must drop a topic due to shifting priorities, lack of time, + or other commitments, notify the list as a courtesy so others can + take over. Anyone can resurrect the topic later when they have the + capacity to do so. + +. Topics with unaddressed review comments that remain inactive for + four weeks may be discarded by the maintainer. + In the following sections, many techniques and conventions are listed to help your patches get reviewed effectively in such a life cycle.
Signature · 1 line
2.55.0-302-gdbd766b094
Re: [PATCH v2] SubmittingPatches: document how to retract a topic
Quoted 32 lines · Junio C Hamano
While this document outlines an idealized lifecycle where an author develops a patch, refines it with reviewer feedback, and successfully merges it into Git, reality is rarely so seamless.
Sometimes, a topic must be abandoned. Doing so explicitly is far better than leaving it in limbo, especially since topics can always be resurrected later.
Clearly state that we encourage contributors to retract any topic that does not pan out.
Signed-off-by Junio C Hamano <[email protected]>---
* Added the third bullet that talks about when and how a topic becomes stalled and discarded.
Documentation/SubmittingPatches | 14 ++++++++++++++ 1 file changed, 14 insertions(+)Documentation/SubmittingPatches +4
-0@@ -123,6 +123,20 @@ of review. top, it gets merged to the 'master' branch and waits to become part of the next major release. +But sometimes things do not work as planned: + +. If a mailing list discussion convinces you that your changes aren't + ideal, please explicitly retract the topic to save the maintainer
Documentation/SubmittingPatches of review. · line 139
Quoted 10 lines
Documentation/SubmittingPatches +10
-0+ time and effort. + +. If you must drop a topic due to shifting priorities, lack of time, + or other commitments, notify the list as a courtesy so others can + take over. Anyone can resurrect the topic later when they have the + capacity to do so. + +. Topics with unaddressed review comments that remain inactive for + four weeks may be discarded by the maintainer. +
Nice, I think these points read smoothly and the additional "four weeks until may be discarded" guidance is helpful.
LGTM.