From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============6704081206327401274=="
MIME-Version: 1.0
From: Mat Martineau <mathew.j.martineau at linux.intel.com>
To: mptcp at lists.01.org
Subject: Re: [MPTCP] [Weekly meetings] MoM - 25th of April 2019
Date: Tue, 30 Apr 2019 16:18:31 -0700
Message-ID: <alpine.OSX.2.21.1904301543190.11303@mjkendri-mobl1.amr.corp.intel.com>
In-Reply-To: 9389e3991a4f5c600a6cb70724b2a4c3c1bc976b.camel@redhat.com
X-Status: 
X-Keywords:                  
X-UID: 1104

--===============6704081206327401274==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


On Tue, 30 Apr 2019, Paolo Abeni wrote:

> Hi,
>
> On Mon, 2019-04-29 at 11:02 -0700, Mat Martineau wrote:
>> If we can merge the beginning of the patch set in our repo, I think it
>> will be much easier to coordinate our work by appending commits rather
>> than constantly revising the whole series. I think we're getting close to
>> that point, and after the pushing RFCv10 we may be in a good position to
>> merge the earlier patches and then focus on new commits (or commits that
>> can be easily squashed).
>
> I agree with this kind of approach. I would take it to the extent of
> accepting the patchset as is, and than handle whatever is needed with
> incremental patches.
>
> WDYT?
>

I'd like to know what others think too. Now that we have more people =

modifying the kernel code, we need a process that gives more visibility =

and doesn't leave people waiting between RFC revisions. I agree that =

incremental patches would let us move forward better, even if we have to =

do some squashing and rearranging later.

--
Mat Martineau
Intel

--===============6704081206327401274==--