[dpdk-dev] DPDK patch backlog

[dpdk-dev] DPDK patch backlog

[Stephen Hemminger]

There are currently 428 patches in New state in DPDK patchwork.

Thomas, could you start reducing that backlog?
The simplest solution would be to merge some of the big patch series
from Intel for the base drivers, then reviewers can focus on the other
patches.

Re: [dpdk-dev] DPDK patch backlog

[Zhu, Heqing]

+1

-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
Sent: Friday, October 16, 2015 5:44 AM
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: [dpdk-dev] DPDK patch backlog

There are currently 428 patches in New state in DPDK patchwork.

Thomas, could you start reducing that backlog?
The simplest solution would be to merge some of the big patch series from Intel for the base drivers, then reviewers can focus on the other patches.

Re: [dpdk-dev] DPDK patch backlog

[Lu, Wenzhuo]

Hi Hemminger,
+1

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhu, Heqing
> Sent: Friday, October 16, 2015 10:47 AM
> To: Stephen Hemminger; Thomas Monjalon
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] DPDK patch backlog
> 
> +1
> 
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Friday, October 16, 2015 5:44 AM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] DPDK patch backlog
> 
> There are currently 428 patches in New state in DPDK patchwork.
> 
> Thomas, could you start reducing that backlog?
> The simplest solution would be to merge some of the big patch series from Intel
> for the base drivers, then reviewers can focus on the other patches.
I think Thomas still needs some reason. Would you like to ack my patches for e1000 base driver :)

Re: [dpdk-dev] DPDK patch backlog

[Thomas Monjalon]

2015-10-15 14:44, Stephen Hemminger:
> There are currently 428 patches in New state in DPDK patchwork.
> 
> Thomas, could you start reducing that backlog?

Yes

> The simplest solution would be to merge some of the big patch series
> from Intel for the base drivers, then reviewers can focus on the other
> patches.

That's why having a drivers/net subtree would be useful.

Re: [dpdk-dev] DPDK patch backlog

[Neil Horman]

On Fri, Oct 16, 2015 at 10:45:23AM +0200, Thomas Monjalon wrote:
> 2015-10-15 14:44, Stephen Hemminger:
> > There are currently 428 patches in New state in DPDK patchwork.
> > 
> > Thomas, could you start reducing that backlog?
> 
> Yes
> 
> > The simplest solution would be to merge some of the big patch series
> > from Intel for the base drivers, then reviewers can focus on the other
> > patches.
> 
> That's why having a drivers/net subtree would be useful.
> 

Agreed, a dpdk-next tree would really be the solution here.

Neil

Re: [dpdk-dev] DPDK patch backlog

[Qiu, Michael]

On 2015/10/16 22:25, Neil Horman wrote:
> On Fri, Oct 16, 2015 at 10:45:23AM +0200, Thomas Monjalon wrote:
>> 2015-10-15 14:44, Stephen Hemminger:
>>> There are currently 428 patches in New state in DPDK patchwork.
>>>
>>> Thomas, could you start reducing that backlog?
>> Yes
>>
>>> The simplest solution would be to merge some of the big patch series
>>> from Intel for the base drivers, then reviewers can focus on the other
>>> patches.
>> That's why having a drivers/net subtree would be useful.
>>
> Agreed, a dpdk-next tree would really be the solution here.

Can't agree more :)

Thanks,
Michael
> Neil
>
>

Re: [dpdk-dev] DPDK patch backlog

[Stephen Hemminger]

Patch backlog is not getting better, now at 486.

How can we break this logjam?
Do I need to make a new "ready for merge" tree?

Re: [dpdk-dev] DPDK patch backlog

[Thomas Monjalon]

2015-10-20 21:34, Stephen Hemminger:
> Patch backlog is not getting better, now at 486.
> 
> How can we break this logjam?
> Do I need to make a new "ready for merge" tree?

What would mean "ready for merge"?
A lot of patches are acked but do not compile or doc is missing.

I have the feeling it would become easier if there were mailing-list, patchwork
and git tree dedicated to some areas. What about starting with drivers/net?

Re: [dpdk-dev] DPDK patch backlog

[Panu Matilainen]

On 10/21/2015 11:25 AM, Thomas Monjalon wrote:
> 2015-10-20 21:34, Stephen Hemminger:
>> Patch backlog is not getting better, now at 486.
>>
>> How can we break this logjam?
>> Do I need to make a new "ready for merge" tree?
>
> What would mean "ready for merge"?
> A lot of patches are acked but do not compile or doc is missing.

Well, isn't that one quite reasonable definition of being "ready"?
- patch must be acked
- patch must apply and compile (when relevant)
- is appropriately documented (commit message style and all)

- Panu -

>
> I have the feeling it would become easier if there were mailing-list, patchwork
> and git tree dedicated to some areas. What about starting with drivers/net?
>

Re: [dpdk-dev] DPDK patch backlog

[Thomas Monjalon]

2015-10-21 11:48, Panu Matilainen:
> On 10/21/2015 11:25 AM, Thomas Monjalon wrote:
> > 2015-10-20 21:34, Stephen Hemminger:
> >> Patch backlog is not getting better, now at 486.
> >>
> >> How can we break this logjam?
> >> Do I need to make a new "ready for merge" tree?
> >
> > What would mean "ready for merge"?
> > A lot of patches are acked but do not compile or doc is missing.
> 
> Well, isn't that one quite reasonable definition of being "ready"?
> - patch must be acked
> - patch must apply and compile (when relevant)
> - is appropriately documented (commit message style and all)

Yes.
Compilation must be tested with GCC and clang, as static and shared libraries
and for 32-bit and 64-bit targets.
Documented means good commit message and doc or release notes updated.

Re: [dpdk-dev] DPDK patch backlog

[Matthew Hall]

On Wed, Oct 21, 2015 at 11:03:41AM +0200, Thomas Monjalon wrote:
> Compilation must be tested with GCC and clang, as static and shared libraries
> and for 32-bit and 64-bit targets.

Is this process scripted somewhere?

Matthew.

Re: [dpdk-dev] DPDK patch backlog

[Thomas Monjalon]

2015-10-21 10:41, Matthew Hall:
> On Wed, Oct 21, 2015 at 11:03:41AM +0200, Thomas Monjalon wrote:
> > Compilation must be tested with GCC and clang, as static and shared libraries
> > and for 32-bit and 64-bit targets.
> 
> Is this process scripted somewhere?

Yes, I've sent a script:
	http://dpdk.org/dev/patchwork/patch/7952/

Re: [dpdk-dev] DPDK patch backlog

[Qiu, Michael]

On 2015/10/21 17:05, Thomas Monjalon wrote:
> 2015-10-21 11:48, Panu Matilainen:
>> On 10/21/2015 11:25 AM, Thomas Monjalon wrote:
>>> 2015-10-20 21:34, Stephen Hemminger:
>>>> Patch backlog is not getting better, now at 486.
>>>>
>>>> How can we break this logjam?
>>>> Do I need to make a new "ready for merge" tree?
>>> What would mean "ready for merge"?
>>> A lot of patches are acked but do not compile or doc is missing.
>> Well, isn't that one quite reasonable definition of being "ready"?
>> - patch must be acked
>> - patch must apply and compile (when relevant)
>> - is appropriately documented (commit message style and all)
> Yes.
> Compilation must be tested with GCC and clang, as static and shared libraries
> and for 32-bit and 64-bit targets.
> Documented means good commit message and doc or release notes updated.

What about bug fix patches?

Thanks,
Michael
>

Re: [dpdk-dev] DPDK patch backlog

[Neil Horman]

On Wed, Oct 21, 2015 at 10:25:12AM +0200, Thomas Monjalon wrote:
> 2015-10-20 21:34, Stephen Hemminger:
> > Patch backlog is not getting better, now at 486.
> > 
> > How can we break this logjam?
> > Do I need to make a new "ready for merge" tree?
> 
> What would mean "ready for merge"?
> A lot of patches are acked but do not compile or doc is missing.
I would think that many of these patches that don't compile should be marked as
rejected in patchwork, and a note sent to the list.  If you can enable the
patchwork xmlrpc interface, we could script/automate that process


Neil

> 
> I have the feeling it would become easier if there were mailing-list, patchwork
> and git tree dedicated to some areas. What about starting with drivers/net?
> 
>