From: Stefano Brivio <sbrivio@redhat.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] how to submit fixes for i40e/i40evf?
Date: Fri, 25 Aug 2017 22:52:15 +0200 [thread overview]
Message-ID: <20170825225215.35fc6b59@elisabeth> (raw)
Hi,
As I'm currently preparing another fix for i40e, and the last one I
submitted has been stuck for about two weeks now, I would like to ask
some details about the process to submit fixes for i40e/i40evf drivers,
before I do something wrong again.
Do all the patches have to go through Intel's patchwork, no matter
what's the perceived severity of the issue? Should I still submit them
to netdev anyway?
Which trees should I check before submitting a patch? Is it enough to
check the master branch of jkirsher/net-queue.git and
jkirsher/next-queue.git?
Once patches reach Intel's patchwork, will they need to wait for some
kind of periodically scheduled pull request process?
I don't know if a process is actually defined at this level of detail,
but still I feel it's wrong that an obvious fix for a potential crash is
waiting in some sort of limbo for 10 days now. Sure, worse things
happen in the world, but I can't understand what this patch is waiting
for.
Any answer is appreciated. Thanks,
--
Stefano
WARNING: multiple messages have this Message-ID (diff)
From: Stefano Brivio <sbrivio@redhat.com>
To: "David S. Miller" <davem@davemloft.net>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org
Subject: how to submit fixes for i40e/i40evf?
Date: Fri, 25 Aug 2017 22:52:15 +0200 [thread overview]
Message-ID: <20170825225215.35fc6b59@elisabeth> (raw)
Hi,
As I'm currently preparing another fix for i40e, and the last one I
submitted has been stuck for about two weeks now, I would like to ask
some details about the process to submit fixes for i40e/i40evf drivers,
before I do something wrong again.
Do all the patches have to go through Intel's patchwork, no matter
what's the perceived severity of the issue? Should I still submit them
to netdev anyway?
Which trees should I check before submitting a patch? Is it enough to
check the master branch of jkirsher/net-queue.git and
jkirsher/next-queue.git?
Once patches reach Intel's patchwork, will they need to wait for some
kind of periodically scheduled pull request process?
I don't know if a process is actually defined at this level of detail,
but still I feel it's wrong that an obvious fix for a potential crash is
waiting in some sort of limbo for 10 days now. Sure, worse things
happen in the world, but I can't understand what this patch is waiting
for.
Any answer is appreciated. Thanks,
next reply other threads:[~2017-08-25 20:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-25 20:52 Stefano Brivio [this message]
2017-08-25 20:52 ` how to submit fixes for i40e/i40evf? Stefano Brivio
2017-08-25 22:10 ` [Intel-wired-lan] " Alexander Duyck
2017-08-25 22:10 ` Alexander Duyck
2017-08-25 22:28 ` Stefano Brivio
2017-08-25 22:28 ` Stefano Brivio
2017-08-28 17:00 ` Alexander Duyck
2017-08-28 17:00 ` Alexander Duyck
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=20170825225215.35fc6b59@elisabeth \
--to=sbrivio@redhat.com \
--cc=intel-wired-lan@osuosl.org \
/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.