From: "Steve Wise" <swise@opengridcomputing.com>
To: "'David Miller'" <davem@davemloft.net>
Cc: <rajur@chelsio.com>, <dledford@redhat.com>,
<linux-rdma@vger.kernel.org>, <jgg@ziepe.ca>,
<netdev@vger.kernel.org>, <bharat@chelsio.com>,
<ganeshgr@chelsio.com>, <rahul.lakkireddy@chelsio.com>
Subject: RE: interdependencies with cxgb4 and iw_cxgb4
Date: Tue, 20 Mar 2018 10:08:44 -0500 [thread overview]
Message-ID: <3d6501d3c05d$571a28a0$054e79e0$@opengridcomputing.com> (raw)
In-Reply-To: <20180320.104046.957152577341740274.davem@davemloft.net>
> >> > Let me ask a dumb question:� Why cannot one of the maintaners pull
> the
> >> > commit from the other mainainer's git repo directly?� IE why have
this
> >> > third trusted/signed git repo that has to be on k.o, from which both
> >> > maintainers pull?� If one of you can pull it in via a patch series,
> >> > like you do for all other patches, and then notify the other
> >> > maintainer to pull it from the first maintainers' repo if the series
> >> > meets the requirements that it needs to be in both maintainers'
> >> > repositories?� This avoids adding more staging git repos on k.o.� But
> >> > probably I'm missing something...
> >>
> >> Tree A may not want all of tree B's changes, and vice versa.
> >
> > I was thinking the special commit would go into a branch that was based
> on,
> > say rc1 or rc2 of one of the maintainers. Then both maintainers pull
that
> > into their -next branch. Would that work?
>
> That makes things more complicated.
For the maintainers, yes. But it avoids setting up k.o accounts and git
repos for each device driver maintainer that has this issue.
>
> The simplest design is that "identical" commits end up in both the
> RDMA and the net-next tree.
>
> Then it absolutely doesn't matter whose tree goes into Linus's first.
>
Yes, and that would still be the case, from my understanding: Instead of
each driver having a k.o. signed git repo, we ask the maintainers to stage
this common branch that both maintainers pull from into their -next
branches/repos.
> Also, we should not be merging "merge window" code after -rc1. "-rc1"
> means the merge window is closed.
I meant using rc-1 for the current release when submitting these shared
commits for the _following merge window_.
Steve.
next prev parent reply other threads:[~2018-03-20 15:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-14 15:31 interdependencies with cxgb4 and iw_cxgb4 Steve Wise
2018-03-16 16:21 ` David Miller
2018-03-19 19:50 ` Steve Wise
2018-03-19 23:34 ` David Miller
2018-03-20 13:47 ` Steve Wise
2018-03-20 14:03 ` Leon Romanovsky
2018-03-20 14:40 ` David Miller
2018-03-20 15:08 ` Steve Wise [this message]
2018-03-20 15:18 ` David Miller
2018-03-20 15:20 ` Steve Wise
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='3d6501d3c05d$571a28a0$054e79e0$@opengridcomputing.com' \
--to=swise@opengridcomputing.com \
--cc=bharat@chelsio.com \
--cc=davem@davemloft.net \
--cc=dledford@redhat.com \
--cc=ganeshgr@chelsio.com \
--cc=jgg@ziepe.ca \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rahul.lakkireddy@chelsio.com \
--cc=rajur@chelsio.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.