All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v6 1/7] powerpc: Extract EPAPR_MAGIC constants into processor.h
Date: Tue, 30 Oct 2012 09:44:46 -0700	[thread overview]
Message-ID: <509003FE.5060203@ti.com> (raw)
In-Reply-To: <508FD713.6070802@denx.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/30/12 06:33, Stefan Roese wrote:
> Hi Wolfgang,
> 
> On 10/30/2012 12:05 PM, Wolfgang Denk wrote:
[snip]
>> 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.
> 
> As you have already guessed, I'm in favoring the 2nd option,
> versioning on a per-series base.
> 
> What do other developers have to say? What's the recommended way to
> do this in the Linux world? Even if we don't need to do everything
> in the same way as done in Linux development, it is much easier to
> do it in a similar fashion for users working in both projects
> (U-Boot & Linux) regularly.

So, I am in favor of per-series versioning.  I also prefer whole
reposting (which I believe to be the norm in the kernel) with a dash
of common sense (posting just 1/7 makes sense here) due to how
patchwork bundles work.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQkAP+AAoJENk4IS6UOR1WNMkP/i7oxy0L7W2N6h730IsDgE9g
tHlgbBUsm5pWnqBC8/57mOmsWWv+j3zgojc3OYMasIyAkHpAJ2yM7qoAFxeGmDzS
TyHvb2bswSIoL2pwlems2m0lfx3V7H8StRcZjpeztfbWRbQXIkKeAon0Bd5R+iwm
v/mIMR6Sdfq+x0klnRIjkO++652nKRQ+JAHLNWNVxZ6DpOqqLBtTAXXyYHLpBEKz
hGdrk2gzryoMAZKiKuiz5mgTmeHoBvsCkIiAsnYoZg94KXohvQUkQzVGV4WA4qOQ
1jk4v7vjGR3gg7c/gOjauwsTalv/6SGZ+f8kSUVV8zKBUOAXhckF0o2+nC70G74W
hoOiSuS2hTz//xkGWmLl9mANCK9iYm/RtQIj4NlrwYabmQ0oUpHRv2HU2C47tffD
u/9RrRqj4onjNR4GtYiy8M4iDFZSiVRpNF6TozxKWyXt2fG01tAPmkdy2mLqfdD5
Mbn0KKBV+/PkPrvzmX0xrFEJVhiMo4P4gUPESLADTX0Xd3oziVKpKjQTRIOpztIT
ib98JeA5fMKPQJJnMnKwldU/0gek5JYpqFihwZMPf5lXi2G3beAXRPTOgZGif621
dCyWbfMEd/fI6393wFvODLjzKT09Q1uf6KxMitrziUEZBB6QVZYRQMKmz5Adz9v0
E9tj91WHgpF9zXOhQgkq
=OWfZ
-----END PGP SIGNATURE-----

  parent reply	other threads:[~2012-10-30 16:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-30  9:45 [U-Boot] [PATCH v6 1/7] powerpc: Extract EPAPR_MAGIC constants into processor.h Stefan Roese
2012-10-30 10:04 ` Wolfgang Denk
2012-10-30 10:16   ` Stefan Roese
2012-10-30 11:05     ` Wolfgang Denk
2012-10-30 13:33       ` Stefan Roese
2012-10-30 15:43         ` Simon Glass
2012-10-30 16:44         ` Tom Rini [this message]
2012-11-07 22:43 ` Anatolij Gustschin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=509003FE.5060203@ti.com \
    --to=trini@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.