From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org
Subject: Re: proposal deadline
Date: Tue, 06 Dec 2016 13:45:01 -0800 (PST) [thread overview]
Message-ID: <1919219.0mG3jzDeNO@xps13> (raw)
In-Reply-To: <20161206132544.720c8627@xeon-e3>
2016-12-06 13:25, Stephen Hemminger:
> On Sun, 04 Dec 2016 23:44:51 +0100
> Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
>
> > Hi all,
> >
> > There were a lot of patches v1 submitted these last days, just before the
> > proposal deadline (December 4).
> > It's good to have a lot of features for 17.02, but it means we are going
> > to have a hard time to review, rework and integrate them.
> > I think we should make an effort to send our v1 patches (or RFC) much before
> > the deadline.
> > Or we can make the proposal window shorter, but it would be less flexible.
> > Another way to manage this huge flow: start reviewing the oldest ones.
> > And if there is not enough time for proper review of the latest series,
> > some will be postponed.
> >
> > The statistics diagram of patches proposals (v1) per week are attached.
> > You can also find it at this URL:
> > https://s12.postimg.org/g9uluz9u5/patchesv1.png
> > In case the diagram of v1 patches needs some comments, these were the
> > deadlines for feature proposal:
> > 2015 October 2
> > 2016 January 31
> > 2016 May 9
> > 2016 August 28
> > 2016 December 4
>
> I would separate new features/infrastructure from new drivers.
> In Linux, Linus still takes new driver after the merge window, but not
> new features.
You're right. We are more tolerant with drivers patches after RC1.
But significant/risky patches are not taken in last week(s).
prev parent reply other threads:[~2016-12-06 21:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-04 22:44 proposal deadline Thomas Monjalon
2016-12-06 21:25 ` Stephen Hemminger
2016-12-06 21:45 ` Thomas Monjalon [this message]
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=1919219.0mG3jzDeNO@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.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.