From: Stephen Hemminger <shemminger@vyatta•com>
To: David Miller <davem@davemloft•net>
Cc: shanwei88@gmail•com, xemul@parallels•com, netdev@vger•kernel.org
Subject: Re: [PATCH] unix_diag: use netlink attribute MAX convention
Date: Wed, 25 Apr 2012 12:47:43 -0700 [thread overview]
Message-ID: <20120425124743.5b4fb8a3@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <20120425.150716.1476178549121153876.davem@davemloft.net>
On Wed, 25 Apr 2012 15:07:16 -0400 (EDT)
David Miller <davem@davemloft•net> wrote:
> From: Stephen Hemminger <shemminger@vyatta•com>
> Date: Wed, 25 Apr 2012 11:56:09 -0700
>
> > Do you expect the one utility to use it to have a workaround for
> > a broken initial version.
>
> I'm not taking that risk.
>
> They thought the same exact thing when they did the autofs struct size
> compat fix, and it turned out to break things.
>
> Stephen I have an awesome suggestion for you if you want to avoid this
> in the future, review iproute2 patches more aggressively so you can
> catch things like this earlier. Like, when we can actually still
> safely change things.
Sorry it was more of cross project issue in this case. The original
kernel patch had the problem and was lost in the fog of the other
issues like the unix diag implementation not building.
A community works best if multiple people look at the code.
Don't think I would have spotted it unless I compared it to
other places.
> Because currently you let patches rot in patchwork. There's an
> iproute2 patch in there assigned to you which is 3 months old, that
> simply isn't how this is supposed to work.
>
> I hate to keep beating a dead horse, but you don't stay on top of
> patchwork like you should. The object is not to let patches just
> rot in "Under Review" state for months.
I keep patches that are for -next in that state.
> Either you apply them as soon as possible, or you mark them
> appropriately as "Changes Requested" or "Deferred" so that the
> submitter makes appropriate fixes you've asked for, or resubmits when
> it's more appropriate for the change to go in.
>
> "Under Review" doesn't mean, "I'm waiting for a kernel release with
> the feature". But that's how you use it.
Ok. What is the suggested tag for that.
next prev parent reply other threads:[~2012-04-25 19:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-25 7:15 [PATCH 1/2] ss: fix the incorrect value of total UNIX_DIAG_* number Shan Wei
2012-04-25 16:26 ` Stephen Hemminger
2012-04-25 17:38 ` [PATCH] unix_diag: use netlink attribute MAX convention Stephen Hemminger
2012-04-25 18:16 ` David Miller
2012-04-25 18:56 ` Stephen Hemminger
2012-04-25 19:07 ` David Miller
2012-04-25 19:47 ` Stephen Hemminger [this message]
2012-04-25 19:57 ` David Miller
2012-04-25 20:09 ` Stephen Hemminger
2012-04-25 20:12 ` David Miller
2012-04-25 20:21 ` [PATCH 1/2] ss: fix the incorrect value of total UNIX_DIAG_* number Stephen Hemminger
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=20120425124743.5b4fb8a3@nehalam.linuxnetplumber.net \
--to=shemminger@vyatta$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shanwei88@gmail$(echo .)com \
--cc=xemul@parallels$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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