6:28 p.m.
Hello,
We just had our 47th meeting with Mat and Peter (Intel OTC),
Christoph (Apple), Florian (Red Hat) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
Initial architecture:
- Paolo will do a new iteration of his fixes/improvement we
discussed last week
- new patch set:
https://lists.01.org/pipermail/mptcp/2019-April/001080.html → mptcp
option len must be skb independent (in progress)
- Mat & Peter and Paolo (problem with the receive destination cache
expired) might not look at the same bug.
- Mat & Peter are working on a new version with some
refactoring/cleanup already discussed on Gerrit (new internal header, no
more magic numbers, etc.)
- Mat is finishing his use-after-free issue (on the ULP listening
socket)
- Mat & Peter hope to push to Gerrit soon!
Next steps:
- Mat & Peter: share the new version
- Review of ↑
- Integrate bug fixes/improvements from Paolo
- discuss next week about what to do with the shared received windows
- merge stuff in our repo
- prepare something to share with Eric
mptcp.org:
- MPTCP v1 still in RFC, no comment so far.
- we can use it to test the upstream version with this v1 (the goal
is for us to only support the v1)
Next meeting:
- We propose to have it next Thursday, the 2nd of May.
- Usual time: 16:00 UTC (9am PDT, 6pm CEST)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20190502
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you next week,
Matthieu
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
2:29 a.m.
On Thu, 25 Apr 2019, Matthieu Baerts wrote:
- Mat & Peter hope to push to Gerrit soon!
Unfortunately I couldn't get this pushed out this week, we got bogged down
resolving some conflicts and I'd like to squash some recent changes from
the mailing list. But like the above says, soon!
--
Mat Martineau
Intel
3:29 p.m.
Hi,
On Thu, 2019-04-25 at 18:28 +0200, Matthieu Baerts wrote:
Initial architecture:
- Paolo will do a new iteration of his fixes/improvement we
discussed last week
I think I'll wait for Mat's rework to post next iteration, to avoid
conflicts - unless others have different opinions.
Apropos: keeping track of the pending patches is quite difficult for
me. Do others have similar issues?
I think/hope that a more incremental approach (merge the patches
eariler - especially bug-fixes - and ev. do follow-up if needed) could
simplify the situation. WDYT?
Thanks,
Paolo
4 p.m.
Hi Paolo,
On Mon, Apr 29, 2019 at 3:29 PM Paolo Abeni <pabeni(a)redhat.com> wrote:
Hi,
On Thu, 2019-04-25 at 18:28 +0200, Matthieu Baerts wrote:
> Initial architecture:
> - Paolo will do a new iteration of his fixes/improvement we
> discussed last week
I think I'll wait for Mat's rework to post next iteration, to avoid
conflicts - unless others have different opinions.
Apropos: keeping track of the pending patches is quite difficult for
me. Do others have similar issues?
I think/hope that a more incremental approach (merge the patches
eariler - especially bug-fixes - and ev. do follow-up if needed) could
simplify the situation. WDYT?
I understand it is not easy to keep track.
The original idea was to merge Mat & Peter's patch-set in our repo
once they are accepted (+2) in Gerrit
https://review.gerrithub.io/c/multipath-tcp/mptcp_net-next/+/448886/2
Then we hope it will be easier and quicker to maintain these patches.
Do you think we could go for this approach? Or do you think it will
still be hard to keep track and maintain everything?
Best regards,
Matthieu
Thanks,
Paolo
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
8:02 p.m.
On Mon, 29 Apr 2019, Matthieu Baerts wrote:
Hi Paolo,
On Mon, Apr 29, 2019 at 3:29 PM Paolo Abeni <pabeni(a)redhat.com> wrote:
>
> Hi,
>
> On Thu, 2019-04-25 at 18:28 +0200, Matthieu Baerts wrote:
>> Initial architecture:
>> - Paolo will do a new iteration of his fixes/improvement we
>> discussed last week
>
> I think I'll wait for Mat's rework to post next iteration, to avoid
> conflicts - unless others have different opinions.
>
> Apropos: keeping track of the pending patches is quite difficult for
> me. Do others have similar issues?
This is an issue with the way we're doing things currently.
We've been making changes based on gerrit feedback across the patch set.
This creates a couple of challenges:
1: The information about what's getting fixed is spread across different
reviews in gerrit
2: Changing things early in the series involves the extra work of
resolving conflicts and testing throughout the series
It's definitely important to improve what we're doing to keep everyone
informed about what is going on, and to make it easier to coordinate now
that we have more contributors.
>
> I think/hope that a more incremental approach (merge the patches
> eariler - especially bug-fixes - and ev. do follow-up if needed) could
> simplify the situation. WDYT?
I understand it is not easy to keep track.
The original idea was to merge Mat & Peter's patch-set in our repo
once they are accepted (+2) in Gerrit
https://review.gerrithub.io/c/multipath-tcp/mptcp_net-next/+/448886/2
Then we hope it will be easier and quicker to maintain these patches.
Do you think we could go for this approach? Or do you think it will
still be hard to keep track and maintain everything?
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).
--
Mat Martineau
Intel
4:29 p.m.
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?
Thanks,
Paolo
1:18 a.m.
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
5:53 p.m.
Paolo Abeni <pabeni(a)redhat.com> wrote:
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.
Also agree. Squashing simple changes (test case improvements, spelling
fixes and so on) is fine but for everything else I would prefer new commits.
There can be one larger rebase/squash effort once its decided that a
netdev rfc submission is to be made.
Until then, constant rebasing is just a waste of time imo.
New commits-on-top would make it easier to track development too.
6:58 p.m.
Hi Florian,
On 02/05/2019 17:53, Florian Westphal wrote:
Paolo Abeni <pabeni(a)redhat.com> wrote:
> 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.
Also agree. Squashing simple changes (test case improvements, spelling
fixes and so on) is fine but for everything else I would prefer new commits.
There can be one larger rebase/squash effort once its decided that a
netdev rfc submission is to be made.
Until then, constant rebasing is just a waste of time imo.
New commits-on-top would make it easier to track development too.
Sorry, I just saw your email now and understood what Paolo and Mat were
saying about incremental patches: we can focus on new commits and rebase
later.
Anyway I guess it is easier if one person does that to avoid working on
a different base.
As I use to work with TopGit, I think it is not an issue for me to
maintain the code with this tool. If one fix is linked to one commit, I
can cherry-pick/apply the fix in the right topic. If not, I can also add
a new topic at the end. Except if you think using TopGit will create
more issues for you guys than it will solve?
Thanks,
Matt
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
627
days inactive
634
days old
8 comments
4 participants
participants (4)
-
Florian Westphal -
Mat Martineau -
Matthieu Baerts -
Paolo Abeni