[dpdk-dev] doc: add details on requirements for patch ack and merge
Checks
Commit Message
Add to the contributors guide the requirements and guidelines for
getting patches acked and merged. It details at what point the review
comments and the ack's need to be received in order to have a given
patch merged into a release.
These guidelines are as agreed by the DPDK technical board at the
meeting held on 2017-02-15.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
doc/guides/contributing/patches.rst | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
Comments
2017-02-21 12:02, Bruce Richardson:
> +#. Once a patch has been acked by the relevant maintainer, reviewers may still comment on it for a further
> + two weeks. After that time, the patch should be merged into the relevent git tree for the next release.
> + Additional notes and restrictions:
> +
> + * patches should be acked by a maintainer at least two days before the release merge
> + deadline, in order to make that release.
> + * for patches acked with less than two weeks to go to the merge deadline, all additional
> + comments should be made no later than two days before the merge deadline.
Do we need a drawing to illustrate the deadlines? :)
> + * after the appropriate time for additional feedback has passed, if the patch has not yet
> + been merged to the relevant tree by the committer, it should be treated as though it had,
> + in that any additional changes needed to it must be addressed by a follow-on patch, rather
> + than rework of the original.
> + * trivial patches may be merged sooner than described above at the tree committer's
> + discretion.
Is it a trivial patch or should I wait 2 weeks before merging this one?
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
On Tue, Feb 21, 2017 at 03:12:32PM +0100, Thomas Monjalon wrote:
> 2017-02-21 12:02, Bruce Richardson:
> > +#. Once a patch has been acked by the relevant maintainer, reviewers may still comment on it for a further
> > + two weeks. After that time, the patch should be merged into the relevent git tree for the next release.
> > + Additional notes and restrictions:
> > +
> > + * patches should be acked by a maintainer at least two days before the release merge
> > + deadline, in order to make that release.
> > + * for patches acked with less than two weeks to go to the merge deadline, all additional
> > + comments should be made no later than two days before the merge deadline.
>
> Do we need a drawing to illustrate the deadlines? :)
>
> > + * after the appropriate time for additional feedback has passed, if the patch has not yet
> > + been merged to the relevant tree by the committer, it should be treated as though it had,
> > + in that any additional changes needed to it must be addressed by a follow-on patch, rather
> > + than rework of the original.
> > + * trivial patches may be merged sooner than described above at the tree committer's
> > + discretion.
>
> Is it a trivial patch or should I wait 2 weeks before merging this one?
The "trivial" is up to you as committer. The 2 weeks depends on when
John acks it as docs maintainer. :-P
>
> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Tuesday, February 21, 2017 12:03 PM
> To: techboard@dpdk.org
> Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>
> Subject: [dpdk-dev] [PATCH] doc: add details on requirements for patch ack
> and merge
>
> Add to the contributors guide the requirements and guidelines for getting
> patches acked and merged. It details at what point the review comments and
> the ack's need to be received in order to have a given patch merged into a
> release.
>
> These guidelines are as agreed by the DPDK technical board at the meeting
> held on 2017-02-15.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Minor nit. I'd prefer the first word of the bullet items to be capitalized
as a sentence. Apart from that:
Acked-by: John McNamara <john.mcnamara@intel.com>
2017-02-21 16:16, Mcnamara, John:
> From: Bruce Richardson
> >
> > Add to the contributors guide the requirements and guidelines for getting
> > patches acked and merged. It details at what point the review comments and
> > the ack's need to be received in order to have a given patch merged into a
> > release.
> >
> > These guidelines are as agreed by the DPDK technical board at the meeting
> > held on 2017-02-15.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>
> Minor nit. I'd prefer the first word of the bullet items to be capitalized
> as a sentence. Apart from that:
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied with capitalization fixed and s/relevent/relevant/.
Thanks
@@ -504,4 +504,20 @@ patch accepted. The general cycle for patch review and acceptance is:
#. In addition a patch will not be accepted if it doesn't address comments from a previous version with fixes or
valid arguments.
-#. Acked patches will be merged in the current or next merge window.
+#. It is the responsibility of a maintainer to ensure that patches are reviewed and to provide an ``ack`` or
+ ``nack`` of those patches as appropriate.
+
+#. Once a patch has been acked by the relevant maintainer, reviewers may still comment on it for a further
+ two weeks. After that time, the patch should be merged into the relevent git tree for the next release.
+ Additional notes and restrictions:
+
+ * patches should be acked by a maintainer at least two days before the release merge
+ deadline, in order to make that release.
+ * for patches acked with less than two weeks to go to the merge deadline, all additional
+ comments should be made no later than two days before the merge deadline.
+ * after the appropriate time for additional feedback has passed, if the patch has not yet
+ been merged to the relevant tree by the committer, it should be treated as though it had,
+ in that any additional changes needed to it must be addressed by a follow-on patch, rather
+ than rework of the original.
+ * trivial patches may be merged sooner than described above at the tree committer's
+ discretion.