public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] Discussion topics / issues
Date: Fri, 10 Oct 2014 13:05:12 +0200	[thread overview]
Message-ID: <E1XcY0Y-0001sF-64@janus> (raw)
In-Reply-To: <20141009230559.GB25685@amd>

Hi Pavel,

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

> On Fri 2014-10-10 00:24:46, Wolfgang Denk wrote:
> > Dear Pavel,
> > 
> > In message <20141009221154.GA24774@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.

  reply	other threads:[~2014-10-10 11:05 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-07 12:45 [U-Boot] [SoCFPGA] next steps Marek Vasut
2014-10-08  8:58 ` Michal Simek
2014-10-08 10:39   ` Marek Vasut
2014-10-08 11:17   ` Pavel Machek
2014-10-08 20:09   ` Tom Rini
2014-10-09  8:37     ` Michal Simek
2014-10-09 11:20       ` Jagan Teki
2014-10-09 13:42         ` Marek Vasut
2014-10-09 16:11           ` Jagan Teki
2014-10-09 16:15             ` [U-Boot] Discussion topics / issues Marek Vasut
2014-10-09 16:41               ` Jagan Teki
2014-10-09 14:03       ` Marek Vasut
2014-10-09 14:45         ` Michal Simek
2014-10-09 15:57           ` Tom Rini
2014-10-09 16:10             ` Marek Vasut
2014-10-09 16:25               ` Tom Rini
2014-10-09 16:29                 ` Marek Vasut
2014-10-09 22:11         ` Pavel Machek
2014-10-09 22:24           ` Wolfgang Denk
2014-10-09 23:00             ` Pavel Machek
2014-10-10 12:22               ` Wolfgang Denk
2014-10-10 14:04                 ` Jeroen Hofstee
2014-10-10 14:26                   ` Marek Vasut
2014-10-10 14:35                     ` Fabio Estevam
2014-10-10 16:09                     ` Jeroen Hofstee
2014-10-10 19:51                       ` Albert ARIBAUD
2014-10-10 20:40                         ` Jeroen Hofstee
2014-10-10 21:13                           ` Albert ARIBAUD
2014-10-11 15:03                           ` Wolfgang Denk
2014-10-11 15:16                             ` Wolfgang Denk
2014-10-15  8:40                             ` [U-Boot] puts() and newlines (was Re: Discussion topics / issues) Pavel Machek
2014-10-15  9:42                               ` Pavel Machek
2014-10-20 15:51                               ` Tom Rini
2014-10-11 14:44                   ` [U-Boot] Discussion topics / issues Wolfgang Denk
2014-10-12 15:06                   ` Jeroen Hofstee
2014-10-09 23:05             ` Pavel Machek
2014-10-10 11:05               ` Albert ARIBAUD [this message]
2014-10-10 12:34               ` Wolfgang Denk
2014-10-10  0:12           ` Tom Rini
2014-10-08 13:18 ` [U-Boot] [SoCFPGA] next steps Dinh Nguyen
2014-10-08 19:05   ` Marek Vasut
2014-10-11 18:22 ` Masahiro YAMADA
2014-10-19 21:19   ` Marek Vasut

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1XcY0Y-0001sF-64@janus \
    --to=albert.u.boot@aribaud.net \
    --cc=u-boot@lists.denx.de \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox