archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <>
To: Christian Eggers <>
Cc: Ido Schimmel <>,
	Richard Cochran <>,
	Andrew Lunn <>,
	Heiner Kallweit <>,
	Jakub Kicinski <>,
	Russell King <>,
	"David S . Miller" <>,,,
	Petr Machata <>, Jiri Pirko <>,
	Ido Schimmel <>
Subject: Re: [PATCH net-next 2/3] mlxsw: spectrum_ptp: use PTP wide message type definitions
Date: Mon, 23 Nov 2020 00:01:12 +0200	[thread overview]
Message-ID: <20201122220112.6ci624wfqp5hefou@skbuf> (raw)
In-Reply-To: <2074851.ybSLjXPktx@n95hx1g2>

On Sun, Nov 22, 2020 at 08:29:22PM +0100, Christian Eggers wrote:
> this was also not by intention. Vladimir found some files I missed in the
> first series. As the whole first series had already been reviewed at that time,
> I wasn't sure whether I am allowed to add further patches to it. Additionally
> I didn't concern that although my local build is successful, I should wait
> until the first series is applied...

When I said that, what I was thinking of (although it might have not
been clear) was that if you send further patches, you send them _after_
the initial series is merged.

Alternatively, it would have been just as valid to resend the entire
series, as a 3+3 patchset with a new revision (v3 -> v4), with review
tags collected from the first three, and the last 3 being completely
new. Jakub could have superseded v3 and applied v4.

The idea behind splicing N patches into a series is that they are
logically connected to one another. For example, a patch doesn't build
without another. You _could_ split logically-connected patches into
separate series and post them independently for review, as long as they
are build-time independent. If they aren't, well, what happens is
exactly what happened: various test robots will report build failures,
which from a maintainer's point of view inspires less confidence to
apply a patch as-is. I would not be surprised if Jakub asked you to
resend with no change at all, just to ensure that the patch series
passes build tests before merging it.

  parent reply	other threads:[~2020-11-22 22:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-22  8:26 [PATCH net-next 0/3] net: ptp: use common defines for PTP message types in further drivers Christian Eggers
2020-11-22  8:26 ` [PATCH net-next 1/3] net: phy: dp83640: use new PTP_MSGTYPE_SYNC define Christian Eggers
2020-11-22  8:26 ` [PATCH net-next 2/3] mlxsw: spectrum_ptp: use PTP wide message type definitions Christian Eggers
2020-11-22 14:35   ` Ido Schimmel
2020-11-22 19:29     ` Christian Eggers
2020-11-22 20:01       ` Ido Schimmel
2020-11-23 22:03         ` Jakub Kicinski
2020-11-22 22:01       ` Vladimir Oltean [this message]
2020-11-23  6:59     ` Ido Schimmel
2020-11-22  8:26 ` [PATCH net-next 3/3] net: phy: mscc: use new PTP_MSGTYPE_* defines Christian Eggers
2020-11-22  9:42   ` kernel test robot
2020-11-23  9:05   ` Antoine Tenart

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:

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

  git send-email \
    --in-reply-to=20201122220112.6ci624wfqp5hefou@skbuf \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).