[U-Boot] Discussion topics / issues

Albert ARIBAUD albert.u.boot at aribaud.net
Fri Oct 10 13:05:12 CEST 2014


Hi Pavel,

On Fri, 10 Oct 2014 01:05:59 +0200, Pavel Machek <pavel at denx.de> wrote:

> On Fri 2014-10-10 00:24:46, Wolfgang Denk wrote:
> > Dear Pavel,
> > 
> > In message <20141009221154.GA24774 at amd> you wrote:
> > > 
> > > Something like this could help..?
> > > 									Pavel
> > > 
> > > --- /dev/null	2014-10-09 01:15:57.354292026 +0200
> > > +++ doc/SubmittingPatches	2014-10-09 23:58:53.058883776 +0200
> > 
> > Is there anything wrong with [1] ?
> > 
> > [1] http://www.denx.de/wiki/U-Boot/Patches
> 
> ..and actually... it makes submitting patches rather hard.
> 
> [PATCH] fix compilation on socfpga
> 
> > Please add tags to the subject
> 
> [PATCHv2] arm: socfpga: fix compilation on socfpga
> 
> > Please add diff from previous version
> 
> [PATCHv3] arm: socfpga: fix compilation on socfpga
> 
> ---
> 
> v2: added tags to the subject

Tags can be useful in automating CC: lists from Patman through
doc/git-mailrc, and as a filtering key in e.g. gitk, hence the
suggestion to add them. Guessing which tags a patch could use is
indeed a tedious and uncertain process, but I don't think it is
requested of many patches, is it?

> v3: added diffs to previous version
> 
> . (From memory, but IIRC something very similar to this happened before).

At least it happened that I requested the change logs when they were
missing entirely in a v2-or-later series. The reason is that with these
logs, reviewers can see what change requests were acknowledged by the
submitter and what other changes were spontaneous additions.

> This scares of all but the most determined patch submitters, and does
> not really improve code quality.

One can argue that it improves code /review/, by both making sure the
submitter has involved the relevant custodians (tags) and provided a
follow-up on their previous remarks (diffs).

Note that patman help a lot about maintaining the change log and tags.

> I'd argue that if only changelog is updated, it is _not_ a new version
> of patch, and does not need changelog diff. Or maybe be less strict
> policy / less strict enforcement of the policy in trivial cases.

Well, if only a changelog is updated, then a [PATCH vN RESEND] should
be as ok as a [PATCH vN+1], and anyway both will end up as "a new
patch" for Patchwork, so the difference is not really major IMO --
meaning both should be accepted and, I believe, are accepted in
practice.

> Best regards,
> 
> 									Pavel

Amicalement,
-- 
Albert.


More information about the U-Boot mailing list