All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw at strlen.de>
To: mptcp at lists.01.org
Subject: Re: [MPTCP] [PATCH MPTCP 0/2] mptcp: token api refactoring/cleanup
Date: Wed, 04 Sep 2019 13:43:37 +0200	[thread overview]
Message-ID: <20190904114337.GH13660@breakpoint.cc> (raw)
In-Reply-To: 9c4b2989-2944-b58d-7f47-29c9eab03700@tessares.net

[-- Attachment #1: Type: text/plain, Size: 2934 bytes --]

Matthieu Baerts <matthieu.baerts(a)tessares.net> wrote:
> I only propose to squash commits to ease the work for later and still
> have a patch-set that can be easy to read, not ending with a lot of "to
> squash" patches. But here I understand that there are conflicts everywhere.

I have no problem with squashing the 'obvious' patches.

> Another possibility is to do the "rebase" directly in the TopGit tree if
> you prefer. I have no issue to give you the "push" permissions and you
> have experience with TopGit. But I can also understand that you prefer
> to postpone the rebase for later (or you don't like TopGit :) )

I would have to take a look at topgit again.  I used it for a short
period but that was more than 6 years ago.

> > The export tree already has a few patches
> > that need to be squashed anyway before sending a formal series.
> 
> That's true. If we want to change that before, simply tell me which
> patches have to be squashed and I can already do the work :)
> 
> > Also, the export branch is currently not bisectable, I get build
> > errors mid-series.
> 
> That has to happen :/

Why?

> Is it something very important if we send the whole patch-set upstream?

Yes, each step on the way needs to result in a compileable tree.
Otherwise, other developers doing 'git bisect' on the kernel later will
may hit this.

> I guess it is better to have "consistent" patches and we will certainly
> fix that but the goal is to merge the whole series.

Of course.  Note that its not a problem to add a function in patch n
and then only add a user in patch n+1 later in the series.

> > Once another patch series is to be submitted to netdev, the export
> > branch can be renamed/archived and a reorganisation can be done at that
> > point (and the result diff'd versus the old export branch to make sure
> > there is no difference in resulting code).
> 
> Sounds good to me!
> We can even re-create another TopGit tree in parallel after the rebase
> if we think that it will take some times before being accepted upstream.

Thats good to know.

> Another question linked to that: do you think it could be possible and a
> good idea to push our code upstream ASAP with known limitations and
> continue our work directly in a dedicated repo from git.kernel.org with
> "regular" merge request for net-next?

I think its good to merge early, but it needs to be well
understood/described where the limits are.

At the moment I don't think we're there yet.

Once mptcp_poll is a bit saner (I added a note to the pad and will be
working on this), we've sorted out token refcounting (also working on
this), Paolos retrans patches are in *and* we can deal with data
arriving on multiple subflows I think we'd be good for a non-rfc
patchset.

IPv6 would be nice but I don't think its a deal-breaker if we'd
place it on the immediate post-merge todo list.

             reply	other threads:[~2019-09-04 11:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-04 11:43 Florian Westphal [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-09-07 15:56 [MPTCP] [PATCH MPTCP 0/2] mptcp: token api refactoring/cleanup Matthieu Baerts
2019-09-05 17:25 Peter Krystad
2019-09-04 12:01 Florian Westphal
2019-09-04 11:53 Matthieu Baerts
2019-09-04 11:16 Matthieu Baerts
2019-09-02 11:09 Florian Westphal

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=20190904114337.GH13660@breakpoint.cc \
    --to=unknown@example.com \
    /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.