[U-Boot] [PATCH v6 1/7] powerpc: Extract EPAPR_MAGIC constants into processor.h

Wolfgang Denk wd at denx.de
Tue Oct 30 12:05:36 CET 2012


Dear Stefan Roese,

In message <508FA904.4070402 at denx.de> you wrote:
> 
> >> ---
> >> Changes in v6:
> >> - Fix compile warning: release.S:354:0: warning: "EPAPR_MAGIC" redefined
...
> 
> As you know this patch is part of a patch-series. And this is the first
> time that this patch has a change. So this summary covers the complete
> history for this patch.

But exactly this is information which I do not have, and which is not
included in your patch.  As is, I can only intepret this to be version
6 of this specific commit, and I wonder which changes were made in the
previous 5 versions.


> In this version of the patch series, I only made this small change to
> this patch 1/7. I wanted to spare the list a resending of the complete
> patchset for such a small change.
> 
> So what is the recommended way to do this? Is it really
> recommended/required to repost the complete patch series upon a small
> change in only one patch? No problem, I can do this. patman makes it
> very easy. :)
> 
> Should I repost the complete series again?

No, not at all!


I understand you are using patman for patch management.  So I added
Simon on Cc: to have his oponion, too.

I see two options:

1) Versioning is done on a per-patch base.  In this case, this patch
   should have been submitted as "[PATCH v2 1/7]", in which case it
   would have been clear to everybody that this is the first and only
   change compared to previous submission(s).

   I don't dare to say "most", but at least some people have worked
   like this when submitting patch series (manually) in the past.
   
   I can understand if somebody argues that it is not exactly easy to
   collect the correspondign patches to a series if individual patches
   contain different version numbers.  Correct threading of the
   messages is essential here.

2) Versioning is done on a per-series base.

   One problem here is that it becomes difficult to keep track if
   what is what when only single patches of the series change and get
   reposted - on the other hand it has always been a major PITA when
   people repost whole series after only changing a line of two in on
   of their many patches, so we strongly encourage posting of only the
   changed patches.  Once more, proper threading appears to be
   essential.

   Another problem is what we are running into here: after severl
   versions of the patch series one patch that has been untouches
   previously gets changed.  Now it gets posted as "V6", and it's
   impossible to know how many previous versions of this patch might
   have been posted before - one? 2? 3? 4? or 5?

   When the version ID refers to the patch series rather than to the
   individual patch, then I think it is mandatory to take this into
   consideration in the patch history, whih then must refer to all
   versions of the _series_.  In the present case, the patch history
   should have looked like this:

	V2: no changes
	V3: no changes
	V4: no changes
	V5: no changes
	V6: Fix compile warning: release.S:354:0: warning: "EPAPR_MAGIC" redefined


Is there any clear majority of preferences for patch versioning?
My gut feeling is that more people would like version IDs on a
per-series base, but I would like to see some confirmation for this,
and the we should document such expectations.


It appears that patman is oriented toward using a single version ID
per series.  Simon - would it be possible to automatically add such
"no changes" information when generating the patches?



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I will also, for an appropriate fee, certify that  your  keyboard  is
object-oriented,  and  that  the bits on your hard disk are template-
compatible.            - Jeffrey S. Haemer in <411akr$3ga at cygnus.com>


More information about the U-Boot mailing list