Hi, On Wed, Aug 28, 2019 at 2:05 PM Johannes Berg <johan...@sipsolutions.net> wrote: > > Hi Doug, > > Some comments on the actual mechanics here (vs. on the kernel list I > picked this up from). > > It seems like perhaps you could increase the "count" variable. You got: > > 20190828132723.0.RFC.Ie6289f437ae533d7fcaddfcee9202f0e92c6b2b9@changeid > > but usually patches are numbered starting from 1, not 0. Especially for > series, it might be easier to understand if that was the same here. > > I'd probably also put it after the tag, so you'd have "RFC.1" instead of > "0.RFC", I'm saying it mostly because I originally thought you somehow > generated a timestamp with a decimal point :-) > > Obviously none of that really matters, but it'd be easier to understand > (and if necessary reverse-engineer) IMHO.
I'm happy to make these changes--they seem sane to me. NOTE that most patches don't actually have a PREFIX but I purposely added one to this patch to test it. :-) The next version will likely have a "version" but no prefix, so with your suggestion I'll have: datetimestring.2.1.Ie6289f437ae533d7fcaddfcee9202f0e92c6b2b9 I may add a "v" before the 2 in the next version also. I was going to do that but then I forgot to before I posted. :-P Thus: datetimestring.v2.1.Ie6289f437ae533d7fcaddfcee9202f0e92c6b2b9 If I post v2 as an RFC also, it would be: datetimestring.RFC.v2.1.Ie6289f437ae533d7fcaddfcee9202f0e92c6b2b9 For now I'll wait a few days before posting a v2 in case anyone wants to provide additional feedback (or tell me that I'm a terrible person for liking Change-Ids). -Doug _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot