[U-Boot] [STATUS] "Quality" of patches / testing.

Jason u-boot at lakedaemon.net
Tue Oct 18 15:49:37 CEST 2011


On Tue, Oct 18, 2011 at 03:13:45PM +0200, Simon Schwarz wrote:
> On 10/18/2011 03:05 PM, Jason wrote:
> >2.) Add a '--versioning' option to format-patch which will scan the
> >	 output directory for previous versions of the patch.
> >	a.) Use the Message-Id of the first version as an In-Reply-To
>
> - Where do you get the Message-Id from? Isn't the message-id assigned
> by the mail system?

'git format-patch' can create it, or 'git send-mail' will add it.
Nothing prevents there from being more than one. 

> - I would prefer the last version

I suppose an example in threaded view might help (yes, not a practical
series, but bear with me :-) ):

[PATCH 0/3] add xyz support.
	[PATCH 1/3] fix some junk
   [PATCH 2/3] add support for xyz board
	[PATCH 3/3] add xyz board to MAKEALL
   [PATCH 0/3 V2] add xyz support.
		[PATCH 1/3 V2] whitespace cleanup
	   [PATCH 2/3 V2] add support for xyz board
		[PATCH 3/3 V2] add xyz board to MAKEALL
	[PATCH 0/2 V3] add xyz support.
		[PATCH 1/2 V3] whitespace cleanup
	   [PATCH 2/2 V3] add support for xyz board
	[PATCH 1/1 V4] add xyz support.
	[PATCH 1/1 V5] add xyz support.

And the cooresponding changelog:

Changes from v1 to v2:
	- proper subject line for whitespace cleanup

Changes from v2 to v3:
	- collapse patch 3 into 2 advised by Prafulla

Changes from v3 to v4:
	- whitespace cleanup was merged

Changes from v4 to v5:
	- rebased against new tag, v2011.09 

By always being In-Reply-To the original coverletter, it's imho, much
easier to find the next version.  Especially once comments and replies
are in the thread.  I suppose '--thread=shallow' could trigger my
approach...

> >	b.) Migrate patch changelog over from previous version, append '***
> >		 ADD CHANGELOG ENTRY HERE ***'
> >	c.) enforce [PATCH 1/7 V#] Subject line format.
>
> Don't forget to remove "V#" for the first version.

Yes, see above.

thx,

Jason.


More information about the U-Boot mailing list