From: Wolfgang Denk <wd@denx.de>
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 12:05:36 +0100 [thread overview]
Message-ID: <20121030110536.ECFBC2001B0@gemini.denx.de> (raw)
In-Reply-To: <508FA904.4070402@denx.de>
Dear Stefan Roese,
In message <508FA904.4070402@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@cygnus.com>
next prev parent reply other threads:[~2012-10-30 11:05 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 [this message]
2012-10-30 13:33 ` Stefan Roese
2012-10-30 15:43 ` Simon Glass
2012-10-30 16:44 ` Tom Rini
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=20121030110536.ECFBC2001B0@gemini.denx.de \
--to=wd@denx.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox