From: Jeff King <peff@peff.net>
To: Philip Oakley <philipoakley@iee.org>
Cc: Junio C Hamano <gitster@pobox.com>,
Christian Couder <christian.couder@gmail.com>,
git@vger.kernel.org, Ben Peart <Ben.Peart@microsoft.com>,
Jonathan Tan <jonathantanmy@google.com>,
Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
Mike Hommey <mh@glandium.org>,
Lars Schneider <larsxschneider@gmail.com>,
Eric Wong <e@80x24.org>,
Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH 0/6] Create Git/Packet.pm
Date: Mon, 30 Oct 2017 11:08:58 -0700 [thread overview]
Message-ID: <20171030180858.e6kp5uwac3kkoaae@sigill.intra.peff.net> (raw)
In-Reply-To: <8F505EA8D16F4A0F890AE9DEEB91434B@PhilipOakley>
On Mon, Oct 23, 2017 at 01:26:41PM +0100, Philip Oakley wrote:
> > Totally offtopic, but is it only me who finds these "section
> > headers" in cover letters from some people irritating and/or
> > jarring?
>
> Personally I find that, for significant patch series, that clearly breaking
> out these distinct sections is of advantage. At this stage (the very first
> patch 0/n) there is no specific conversation, so the subject line is a short
> 'hello' to the topic, and then the contributor is (it is to be hoped)
> setting out their proposal in a clear manner.
>
> So I do like these headings for larger series, though there is some
> judgement to be made as to when the subject line alone is sufficient.
I can live with fancily-formatted cover letters. BUT. I would say if
your cover letter is getting quite long, you might consider whether some
of its content ought to be going elsewhere (either into commit messages
themselves, or into a design document or other place inside the repo).
> As a separate follow on, one thing that does annoy me is that in subsequent
> versions of the various patch series, folk tend to drop all explanation of
> why the series is of any relevance, leaving just the 'changed since last
> time' part. This means that new readers who try and pick up / review /
> contribute to a series later on in its development are not told the purpose.
> When the list is active it can, accidentally, do a disservice to the
> potential contributors who may feel that only core contributors are able to
> contribute.
I actually have the opposite opinion. I find it annoying to have to wade
through the same unchanged content for each round just to find the
little snippet of "here's what's changed".
I don't mind following a link to the previous iteration to read the
back-story if I wasn't involved (it's a good idea to do that anyway to
see what previous reviews have already discussed).
I do often just post my "v2" as a follow-up and assume people can find
the original by following the thread backwards. But I imagine that not
everybody can do so. It's probably a good practice to at least put a
link to the prior version (and also to v1 for the original motivation)
if you're not going to repeat the cover letter in full.
-Peff
next prev parent reply other threads:[~2017-10-30 18:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-19 12:30 [PATCH 0/6] Create Git/Packet.pm Christian Couder
2017-10-19 12:30 ` [PATCH 1/6] t0021/rot13-filter: refactor packet reading functions Christian Couder
2017-10-19 22:01 ` Stefan Beller
2017-10-22 0:58 ` Junio C Hamano
2017-11-05 12:50 ` Christian Couder
2017-10-19 12:30 ` [PATCH 2/6] t0021/rot13-filter: improve 'if .. elsif .. else' style Christian Couder
2017-10-19 12:30 ` [PATCH 3/6] t0021/rot13-filter: improve error message Christian Couder
2017-10-19 12:30 ` [PATCH 4/6] t0021/rot13-filter: add packet_initialize() Christian Couder
2017-10-22 1:12 ` Junio C Hamano
2017-10-27 2:57 ` Junio C Hamano
2017-10-27 5:07 ` Christian Couder
2017-10-28 14:59 ` Lars Schneider
2017-10-29 0:14 ` Junio C Hamano
2017-10-19 12:30 ` [PATCH 5/6] t0021/rot13-filter: add capability functions Christian Couder
2017-10-22 1:46 ` Junio C Hamano
2017-11-04 8:38 ` Christian Couder
2017-11-05 2:03 ` Junio C Hamano
2017-10-19 12:30 ` [PATCH 6/6] Add Git/Packet.pm from parts of t0021/rot13-filter.pl Christian Couder
2017-10-19 22:06 ` Stefan Beller
2017-10-22 2:04 ` [PATCH 0/6] Create Git/Packet.pm Junio C Hamano
2017-10-23 12:26 ` Philip Oakley
2017-10-30 18:08 ` Jeff King [this message]
2017-10-25 23:10 ` Johannes Schindelin
2017-10-26 5:38 ` Junio C Hamano
2017-10-26 9:07 ` Jacob Keller
2017-10-26 9:08 ` Bryan Turner
2017-10-26 9:12 ` Bryan Turner
2017-10-27 15:09 ` Johannes Schindelin
2017-10-27 15:05 ` Johannes Schindelin
2017-10-30 0:38 ` Junio C Hamano
2017-10-30 6:18 ` Christian Couder
2017-10-30 12:37 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171030180858.e6kp5uwac3kkoaae@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=Ben.Peart@microsoft.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=larsxschneider@gmail.com \
--cc=mh@glandium.org \
--cc=pclouds@gmail.com \
--cc=philipoakley@iee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).