Best practices for indicating what address to send patches to?

Best practices for indicating what address to send patches to?

[Philip Kaludercic]

Hi, I was wondering if anyone had a good suggestion on how to indicate
where to send a patch to.  Ideally I'd like to have "sendemail.to"
configured on cloning, but that isn't possible IIUC.  There also doesn't
seem to be a conventional file like ".git-email" that would list where
to send a patch, without having to look it up.

Is this intentional, has it been discussed in the past or is there the
chance that it might be improved upon in the future?

-- 
	Philip Kaludercic on peregrine

Re: Best practices for indicating what address to send patches to?

[Junio C Hamano]

Philip Kaludercic <philipk@posteo.net> writes:

> Hi, I was wondering if anyone had a good suggestion on how to indicate
> where to send a patch to.  Ideally I'd like to have "sendemail.to"
> configured on cloning, but that isn't possible IIUC.  There also doesn't
> seem to be a conventional file like ".git-email" that would list where
> to send a patch, without having to look it up.
>
> Is this intentional, has it been discussed in the past or is there the
> chance that it might be improved upon in the future?

The usual convention is to have the patch submission address (if a
project uses e-mail based patch as its workflow) together with other
rules and guidelines the contributors are expected to adhere to in
documents like README, CONTRIBUTING, etc.  As an e-mailed patch that
does not follow established conventions is not necessarily useful to
the receiving projects, it is a good practice to put these pieces of
information crucial to start contributing in a single place.

It would not be an improvement to add a mechanism to make it easier
to find "here is the address" to a reader who hasn't even discovered
where these contributor guide documents are.

Thanks.

Re: Best practices for indicating what address to send patches to?

[Philip Kaludercic]

Junio C Hamano <gitster@pobox.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Hi, I was wondering if anyone had a good suggestion on how to indicate
>> where to send a patch to.  Ideally I'd like to have "sendemail.to"
>> configured on cloning, but that isn't possible IIUC.  There also doesn't
>> seem to be a conventional file like ".git-email" that would list where
>> to send a patch, without having to look it up.
>>
>> Is this intentional, has it been discussed in the past or is there the
>> chance that it might be improved upon in the future?
>
> The usual convention is to have the patch submission address (if a
> project uses e-mail based patch as its workflow) together with other
> rules and guidelines the contributors are expected to adhere to in
> documents like README, CONTRIBUTING, etc.  As an e-mailed patch that
> does not follow established conventions is not necessarily useful to
> the receiving projects, it is a good practice to put these pieces of
> information crucial to start contributing in a single place.
>
> It would not be an improvement to add a mechanism to make it easier
> to find "here is the address" to a reader who hasn't even discovered
> where these contributor guide documents are.

But is that an argument to prevent projects with mild or now contributor
guidelines to make the patch-driven workflow more difficult?  I've often
contributed to a project by quickly checking out the source code,
changing something and then sending a patch (this is easier in the
context of Emacs, because we have the a `vc-default-patch-addressee'
variable).  My suggestion is by no means to mandate this kind of an
option, but there are situations where this kind of configurability
would be useful, e.g. for Sourcehut projects.

> Thanks.

-- 
	Philip Kaludercic on peregrine

Re: Best practices for indicating what address to send patches to?

[Junio C Hamano]

Philip Kaludercic <philipk@posteo.net> writes:

>> It would not be an improvement to add a mechanism to make it easier
>> to find "here is the address" to a reader who hasn't even discovered
>> where these contributor guide documents are.
>
> But is that an argument to prevent projects with mild or now contributor
> guidelines to make the patch-driven workflow more difficult?

Projects can actively refuse to use such a "feature", if it is
expected to encourage undesirable behaviour by new contributors.
And projects that do not care can use such a "feature". In that
sense, I can see a future in which such a "feature" exists but not
used by everybody.  But introducing such a "feature" that is not
necessarily an improvement and can actively harm projects that use
it is tricky.  You'd have to document the upsides and the downsides
to allow projects to make informed decisions if they want to adopt
it.

Stepping back to your original question, you asked if this is
intentional and if this was discussed in the past.

The answer is this is more organic and not with an explicit
intention, but in hindsight, because submission address is just a
small piece of information projects want to publish together with
other guidelines, not having a mechanism only to give the submission
address would *not* have helped projects all that much.  With the
explanation behind the answer to the first question it should be
easy to see why nobody talked about such a "feature" in the past,
which is the answer to your second question.