diff mbox series

Documentation: specify base point when generating MyFirstContribution patchset

Message ID 20211013122234.448845-1-bagasdotme@gmail.com (mailing list archive)
State Superseded
Headers show
Series Documentation: specify base point when generating MyFirstContribution patchset | expand

Commit Message

Bagas Sanjaya Oct. 13, 2021, 12:22 p.m. UTC
Some reviewers need to know the base point of patchset a contributor
being worked on. Mention how to answer that.

Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
 Documentation/MyFirstContribution.txt | 7 +++++++
 1 file changed, 7 insertions(+)


base-commit: 106298f7f9cca4158a980de149ef217751e1f943

Comments

Junio C Hamano Oct. 13, 2021, 8:30 p.m. UTC | #1
Bagas Sanjaya <bagasdotme@gmail.com> writes:

> +Some reviewers (notably testers) would like to know at what point your patchset
> +are based on (in particular to apply the patchset). In such cases, you can
> +mention the base point when preparing your email (see below section), or by
> +passing `--base=$(git merge-base master psuh)` to `format-patch`. If no base
> +point is specified, the patchset is assumed to be applied on top of current
> +tip of `master` branch.

This document is about contributing to _this_ project, so I think we
can and should be more explicit to say what is preferred, not "some
would like to know, and in such a case you give this extra piece",
as by definition, somebody who is making their first contribution
would not know whether the reviewer who looks at your work is among
these "some" or not.

    It would help those who review and test your patches to make it
    clear on what commit they are meant to apply.  To do so, use the
    "--base" option to record the commit on which you based the
    series when running "git format-patch".

If no base is given, what is assumed by default various by
recipient, so all we could say is "If no base is specified, nothing
is assumed", but let's rather not say anything to confuse the
readers.

We could say what we want to see the first-time contributors do,
but I do not think it is needed in this case.

	Side note. We want a new feature to be built on 'master' (or
	the last feature release, if nothing in flight conflicts
	with it)), and a bugfix to be built on one of the older
	release point (to be applicable to the maintenance tracks).
	But the section we are discussing, i.e. how to run
	format-patch, is not the place to do so, as it is too
	late---it must be decided before the contributor starts
	working on the series.  As the example of this document is
	about adding a new "feature", we should have a sentence to
	explain, in the "Set up your workspace" section, why we
	chose 'master' as the base point (and the existing text
	already says why).

Thanks.
Bagas Sanjaya Oct. 15, 2021, 6:51 a.m. UTC | #2
On 14/10/21 03.30, Junio C Hamano wrote:
> 	Side note. We want a new feature to be built on 'master' (or
> 	the last feature release, if nothing in flight conflicts
> 	with it)), and a bugfix to be built on one of the older
> 	release point (to be applicable to the maintenance tracks).
> 	But the section we are discussing, i.e. how to run
> 	format-patch, is not the place to do so, as it is too
> 	late---it must be decided before the contributor starts
> 	working on the series.  As the example of this document is
> 	about adding a new "feature", we should have a sentence to
> 	explain, in the "Set up your workspace" section, why we
> 	chose 'master' as the base point (and the existing text
> 	already says why).

It has been described before:

> Let's start by making a development branch to work on our changes. Per
> `Documentation/SubmittingPatches`, since a brand new command is a new feature,
> it's fine to base your work on `master`. However, in the future for bugfixes,
> etc., you should check that document and base it on the appropriate branch.

Leave it as is?
Junio C Hamano Oct. 15, 2021, 4:26 p.m. UTC | #3
Bagas Sanjaya <bagasdotme@gmail.com> writes:

>>...
>> 	chose 'master' as the base point (and the existing text
>> 	already says why).
>
> It has been described before:

Yes, re-read what you quoted and you'd find "and the existing text
already says why".

> Leave it as is?

Yes, that section can stay the same, as I said.

In short, everything I said in the message you are responding to
still stands.

Thanks.
diff mbox series

Patch

diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt
index b20bc8e914..081fb71327 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -937,6 +937,13 @@  but want reviewers to look at what they have so far. You can add this flag with
 Check and make sure that your patches and cover letter template exist in the
 directory you specified - you're nearly ready to send out your review!
 
+Some reviewers (notably testers) would like to know at what point your patchset
+are based on (in particular to apply the patchset). In such cases, you can
+mention the base point when preparing your email (see below section), or by
+passing `--base=$(git merge-base master psuh)` to `format-patch`. If no base
+point is specified, the patchset is assumed to be applied on top of current
+tip of `master` branch.
+
 [[cover-letter]]
 === Preparing Email