Re: [PATCH, RFC] A development process document

Randy.Dunlap wrote:
On Thu, 31 Jul 2008, Daniel Barkalow wrote:
On Thu, 31 Jul 2008, Jonathan Corbet wrote:
On Thu, 31 Jul 2008 00:23:05 -0600
Alex Chiang <achiang@xxxxxx> wrote:
+If you have a significant series of patches, it is customary to
send an +introductory description as part zero. In general, the
second and

This directly conflicts with akpm's advice:

http://www.zipworld.com.au/~akpm/linux/patches/stuff/tpp.txt

Section 6(b).

Interesting; Andrew didn't mention that in his review. I think the intro
postings can be very useful in understanding a patch series as a whole.
Maybe I'll put in something about how anything which should be in the
changelogs needs to go with the actual patches.

If you include a [0/N], it's a cover letter, not a changelog portion. It
can be a useful way of providing context to reviewers as to the intended
total effect. Each of the patches should make sense standalone, but it's
not always clear from the individual patches what the total benefit is,
and a 0/N that explains can be worthwhile (and you'd want to make that
announcement to the mailing list, but not get it into the history).

but.. but Andrew often has to take part(s) of #0/N and add them to the
changelog(s) to make the changelog(s) meaningful. I.e., someone skimped
on what should have been in the changelog(s).

That would not be a problem with the cover posting, it would be a
problem with the changelogs. The same applies if the respective
information is put below the '---' delimiter line in the individual
patch postings. So just remember that changelogs need to be
sufficiently comprehensive even when read standalone, out of the context
of the series.

BTW, I always like to see the -> combined diffstat <- of the whole patch
series in 0/N cover postings. For this reason alone, a cover posting is
IMO generally recommendable for series of more than three or four
patches. Especially if the reason for posting is a request for review
rather than transfer to a maintainer.

I think Andrew's advice in tpp is very valid in order to create "the
perfect patch", but not really how to post "the perfect review request".
--
Stefan Richter
-=====-==--- =--- ----=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: How to stop these bluddy spammers...
    ... *could* have any legal consequences. ... Suppose for example that I had indicated that I filter out postings ... then they might sue claiming I had interfered with the grant process. ... sit on grant review panels as "outside examiners"; ...
    (comp.lang.c)
  • Re: new yahoo 80s group to join!
    ... Review your postings, you quoted ... not on purpose, thats for sure. ...
    (uk.culture.nostalgia.1980s)
  • Re: coils?multi-turn magnetic loops
    ... together -- I suggest you review the previous postings which explain it.. ... As far as "better", the answer is that it probably doesn't matter, since ... Wrong one of the several meanings, Dave. ...
    (rec.radio.amateur.antenna)
  • [Patch 0/6] Per-task delay accounting
    ... The comments from earlier postings of these patches have been addressed, ... waiting for a CPU ... Such delays provide feedback for a task's cpu priority, ...
    (Linux-Kernel)
  • Re: Access violation
    ... Might then want to review some of these other postings to get some ideas as ... > I do not have winshow.* files or dict.dat files to delete, ... > TIA ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)