[PATCH 0/8 v4] mpc83xx_wdt rework, support for mpc8610 and mpc8xx

Paul Mackerras paulus at samba.org
Wed Jun 4 14:07:20 EST 2008


Andrew Morton writes:

> On Wed, 4 Jun 2008 04:17:39 +0400
> Anton Vorontsov <avorontsov at ru.mvista.com> wrote:
> 
> > > Please put the subsystem identifier (eg, "watchdog" and "powerpc")
> > > outside the [], for reasons which should be in
> > > Documentation/SubmittingPatches, which used to be there but which got
> > > lost.  Bascially the text inside [] is for temporary not-for-committing
> > > information such as "rfc", "2.6.24-rc4", "resend", etc and should be stripped
> > > by the email recipient before merging.
> > 
> > Yeah, I know. It is just hard to remember all the preferences.
> > 
> > For example, PowerPC maintainers asking to do patches with "[POWERPC]"
> > identifier, this identifier purposely keeps intact for git-log.
> 
> Addition of "[powerpc]" if it was absent can be scripted.
> 
> However, the retaining of "[powerpc]" (etc) while not retaining "[rfc]"
> (etc) is not practical.
> 
> Plus putting things into git with "[powerpc]" in the title is wrong. 
> The chances are good that anyone who is taking such a patch off the
> git-commits list (say, for a backport) will lose that part of the
> title.  It should be "powerpc: "

I think Anton is confusing two things: (a) what should be in the
subject line of a patch posted to a mailing list, and (b) what should
be in the headline of a commit put into a git tree that I pull from.
As for (a), people can put whatever they like in [], and if people put
"powerpc:" in the subject, I edit it out since my scripts put
[POWERPC] in the git commit headline.  For (b), I ask git tree
maintainers that I'm going to pull from to put [POWERPC] at the start
of the headline for consistency with what I do.

Looking at Linus' git tree, it's evident that some subsystems use the
the "[SUBSYSTEM]" notation and some use "subsystem:".  If there is now
an edict from on high that only "subsystem:" is acceptable, then I
must have missed that memo.

Paul.



More information about the Linuxppc-dev mailing list