[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