This merge window...

This merge window...

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 1525 bytes --]

RESEND: I sent this *hours* ago, but accidentally from my personal
account.  I haven't seen it show up on the list yet, so I'm resending
from my work account where my emails seem to make it to the list in a
timely fashion.

As some of you no doubt noticed, when Linus decided to make the last rc
cycle of 4.12 -rc7 and open the merge window last week (on a holiday
week for people in the USA no less), it caught me off guard.  I didn't
have my for-next branch ready to go (it's mostly there, but not all
there), so at Linus' request I'm holding the merge until 4.14.  That
means I'm going to rework my branches entirely (so it's a good thing
I've only pushed them to github so I can rebase at will).  I'll be
moving things that are high priority and fixes from my for-next area
over to my for-rc area and I'll push those through this cycle.  I'll
end up pushing the first round of -rc moves later today, but if you
feel the need to check my for-next area to see if your favorite bug fix
patch is already there and drop me an email off-list to tell me that
you really want that patch in -rc this cycle, then please feel free to
do so.  Otherwise, if you want to just trust in my judgment, in a day
or two I'll have it all sorted and you can just double check then to
make sure your patch made it where you wanted it to go.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: This merge window...

[Or Gerlitz]

On Tue, Jul 11, 2017 at 10:28 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> As some of you no doubt noticed, when Linus decided to make the last rc
> cycle of 4.12 -rc7 and open the merge window last week (on a holiday
> week for people in the USA no less), it caught me off guard.  I didn't
> have my for-next branch ready to go (it's mostly there, but not all
> there), so at Linus' request I'm holding the merge until 4.14.

I didn't see an email from Linus on that request, can you please
elaborate a little further?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: This merge window...

[Doug Ledford]

On Wed, 2017-07-12 at 17:13 +0300, Or Gerlitz wrote:
> On Tue, Jul 11, 2017 at 10:28 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> wrote:
> > As some of you no doubt noticed, when Linus decided to make the
> > last rc
> > cycle of 4.12 -rc7 and open the merge window last week (on a
> > holiday
> > week for people in the USA no less), it caught me off guard.  I
> > didn't
> > have my for-next branch ready to go (it's mostly there, but not all
> > there), so at Linus' request I'm holding the merge until 4.14. 
> 
> 
> I didn't see an email from Linus on that request, can you please
> elaborate a little further?

That's because it was in private email.  I emailed him Monday to let
him know it would probably be Wed before my branch was completed,
including having been through 0day and linux-next testing, and asked if
that would be OK.  He told me to hold it until 4.14 then.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: This merge window...

[Christoph Hellwig]

Can we make sure the tree is simply always in pullable state for the
future?  That's what I do for my (not too important) trees, and that's
the state of many other major trees.    At least past -rc4 or so.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: This merge window...

[Leon Romanovsky]

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

On Wed, Jul 12, 2017 at 09:04:32AM -0700, Christoph Hellwig wrote:
> Can we make sure the tree is simply always in pullable state for the
> future?  That's what I do for my (not too important) trees, and that's
> the state of many other major trees.    At least past -rc4 or so.

It will be awesome and it will minimize chances that -rc1 is broken,
which we had in last cycles.

It works extremely well for rdma-core and I don't see any reason why it
wouldn't work for rdma tree in kernel.

Thanks

> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: This merge window...

[Sagi Grimberg]

>> Can we make sure the tree is simply always in pullable state for the
>> future?  That's what I do for my (not too important) trees, and that's
>> the state of many other major trees.    At least past -rc4 or so.
> 
> It will be awesome and it will minimize chances that -rc1 is broken,
> which we had in last cycles.

Join on the awesomeness.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: This merge window...

[Christopher Lameter]

On Thu, 13 Jul 2017, Sagi Grimberg wrote:

> Join on the awesomeness.

It would even be more awesome if we had multiple people that can work the
release process so that we do not have a single person bottleneck.

Doug: Would you please do some more detailed planning and delegate things
as possible? A couple of developers should be able to review the current
state of things and help to move things forward if there is a bottleneck
currently or coming up.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: This merge window...

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 1130 bytes --]

On 7/14/2017 10:28 AM, Christopher Lameter wrote:
> On Thu, 13 Jul 2017, Sagi Grimberg wrote:
> 
>> Join on the awesomeness.
> 
> It would even be more awesome if we had multiple people that can work the
> release process so that we do not have a single person bottleneck.
> 
> Doug: Would you please do some more detailed planning and delegate things
> as possible? A couple of developers should be able to review the current
> state of things and help to move things forward if there is a bottleneck
> currently or coming up.
> 

I am, without a doubt, reworking my process.  I will not be syncing up
against Dave Miller's tree any more.  When I take patches, they should
apply cleanly to my tree and work without dependencies.  If there are
dependencies, then people need to send the dependencies through Dave's
tree (assuming that's where they go) in release X, and then send the
dependent code to my tree in release X + 1.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: This merge window...

[Leon Romanovsky]

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

On Sat, Jul 15, 2017 at 02:12:42PM -0400, Doug Ledford wrote:
> On 7/14/2017 10:28 AM, Christopher Lameter wrote:
> > On Thu, 13 Jul 2017, Sagi Grimberg wrote:
> >
> >> Join on the awesomeness.
> >
> > It would even be more awesome if we had multiple people that can work the
> > release process so that we do not have a single person bottleneck.
> >
> > Doug: Would you please do some more detailed planning and delegate things
> > as possible? A couple of developers should be able to review the current
> > state of things and help to move things forward if there is a bottleneck
> > currently or coming up.
> >
>
> I am, without a doubt, reworking my process.  I will not be syncing up
> against Dave Miller's tree any more.  When I take patches, they should
> apply cleanly to my tree and work without dependencies.  If there are
> dependencies, then people need to send the dependencies through Dave's
> tree (assuming that's where they go) in release X, and then send the
> dependent code to my tree in release X + 1.

There are two parts in this proposal, while second part (dependency) is
fair enough and possible to meet, it is unclear to me the first part
(apply cleanly).

1. On which branch should we send our topics?
2. Are you acknowledge that this branch is going to be updated +/- on daily basis?
3. How do you see us submitting multiple topics? Sequential submission - like DaveM,
and it should be applied close to submissions (if no objections and so on ..).
Or parallel submissions - like it is now and the conflicts are unavoidable.
4. If 2 and 3 are not going to change, should we wait till late rc and submit all (100+)
patches at one or two shots to avoid merge conflicts?

I would be glad to get the whole picture of submission process, before
we are moving forward.

Thanks

>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG Key ID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: This merge window...

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 2625 bytes --]

On 7/15/2017 11:57 PM, Leon Romanovsky wrote:
> On Sat, Jul 15, 2017 at 02:12:42PM -0400, Doug Ledford wrote:
>> On 7/14/2017 10:28 AM, Christopher Lameter wrote:
>>> On Thu, 13 Jul 2017, Sagi Grimberg wrote:
>>>
>>>> Join on the awesomeness.
>>>
>>> It would even be more awesome if we had multiple people that can work the
>>> release process so that we do not have a single person bottleneck.
>>>
>>> Doug: Would you please do some more detailed planning and delegate things
>>> as possible? A couple of developers should be able to review the current
>>> state of things and help to move things forward if there is a bottleneck
>>> currently or coming up.
>>>
>>
>> I am, without a doubt, reworking my process.  I will not be syncing up
>> against Dave Miller's tree any more.  When I take patches, they should
>> apply cleanly to my tree and work without dependencies.  If there are
>> dependencies, then people need to send the dependencies through Dave's
>> tree (assuming that's where they go) in release X, and then send the
>> dependent code to my tree in release X + 1.
> 
> There are two parts in this proposal, while second part (dependency) is
> fair enough and possible to meet, it is unclear to me the first part
> (apply cleanly).
> 
> 1. On which branch should we send our topics?

You can always use -rc1 as a safe starting point.  I'm going to try to
open things up around then anyway.

> 2. Are you acknowledge that this branch is going to be updated +/- on daily basis?

Not necessarily daily, but certainly every 2-3 days.

> 3. How do you see us submitting multiple topics? Sequential submission - like DaveM,
> and it should be applied close to submissions (if no objections and so on ..).
> Or parallel submissions - like it is now and the conflicts are unavoidable.

Not the parallel submissions we are using now.  It generates far too
many conflicts and such.  What I would prefer to see is one submission,
then two or three days (so the first submission has had some bake time),
then the next one and it should assume the first is applied and apply
cleanly on top of that.

> 4. If 2 and 3 are not going to change, should we wait till late rc and submit all (100+)
> patches at one or two shots to avoid merge conflicts?
> 
> I would be glad to get the whole picture of submission process, before
> we are moving forward.

Is what I wrote above clear enough?


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: This merge window...

[Leon Romanovsky]

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

On Sun, Jul 16, 2017 at 08:46:43AM -0400, Doug Ledford wrote:
> On 7/15/2017 11:57 PM, Leon Romanovsky wrote:
> > On Sat, Jul 15, 2017 at 02:12:42PM -0400, Doug Ledford wrote:
> >> On 7/14/2017 10:28 AM, Christopher Lameter wrote:
> >>> On Thu, 13 Jul 2017, Sagi Grimberg wrote:
> >>>
> >>>> Join on the awesomeness.
> >>>
> >>> It would even be more awesome if we had multiple people that can work the
> >>> release process so that we do not have a single person bottleneck.
> >>>
> >>> Doug: Would you please do some more detailed planning and delegate things
> >>> as possible? A couple of developers should be able to review the current
> >>> state of things and help to move things forward if there is a bottleneck
> >>> currently or coming up.
> >>>
> >>
> >> I am, without a doubt, reworking my process.  I will not be syncing up
> >> against Dave Miller's tree any more.  When I take patches, they should
> >> apply cleanly to my tree and work without dependencies.  If there are
> >> dependencies, then people need to send the dependencies through Dave's
> >> tree (assuming that's where they go) in release X, and then send the
> >> dependent code to my tree in release X + 1.
> >
> > There are two parts in this proposal, while second part (dependency) is
> > fair enough and possible to meet, it is unclear to me the first part
> > (apply cleanly).
> >
> > 1. On which branch should we send our topics?
>
> You can always use -rc1 as a safe starting point.  I'm going to try to
> open things up around then anyway.

No problem, it is the same as we do it anyway for our shared code.

>
> > 2. Are you acknowledge that this branch is going to be updated +/- on daily basis?
>
> Not necessarily daily, but certainly every 2-3 days.

2-3 days in some countries is the same as to say daily :)

>
> > 3. How do you see us submitting multiple topics? Sequential submission - like DaveM,
> > and it should be applied close to submissions (if no objections and so on ..).
> > Or parallel submissions - like it is now and the conflicts are unavoidable.
>
> Not the parallel submissions we are using now.  It generates far too
> many conflicts and such.  What I would prefer to see is one submission,
> then two or three days (so the first submission has had some bake time),
> then the next one and it should assume the first is applied and apply
> cleanly on top of 4hat.

I'm totally in for it. It will simplify greatly the whole my process and
will allow to do more cross-tree work.

Can we move to pull-request model? So our whole submission queue will participate
in linux-next and we will move our testing to use it as a testing branch instead of
our artificial queue-next [1]?

It will allow to all of us to have trees in linux-next, because we will
have same SHA1 and Stephen won't have any merge conflicts between trees.

>
> > 4. If 2 and 3 are not going to change, should we wait till late rc and submit all (100+)
> > patches at one or two shots to avoid merge conflicts?
> >
> > I would be glad to get the whole picture of submission process, before
> > we are moving forward.
>
> Is what I wrote above clear enough?

Thanks, it is much clear.
When do you expect to update your branches so we will be able to prepare our shared code?

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=queue-next

>
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG Key ID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: This merge window...

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 647 bytes --]

On 7/16/2017 10:38 AM, Leon Romanovsky wrote:
> On Sun, Jul 16, 2017 at 08:46:43AM -0400, Doug Ledford wrote:

> I'm totally in for it. It will simplify greatly the whole my process and
> will allow to do more cross-tree work.
> 
> Can we move to pull-request model?

Yes, I'm fine with that.

> Thanks, it is much clear.
> When do you expect to update your branches so we will be able to prepare our shared code?

Tomorrow.  It's the weekend here.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: This merge window...

[Leon Romanovsky]

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

On Sun, Jul 16, 2017 at 11:02:16AM -0400, Doug Ledford wrote:
> On 7/16/2017 10:38 AM, Leon Romanovsky wrote:
> > On Sun, Jul 16, 2017 at 08:46:43AM -0400, Doug Ledford wrote:
>
> > I'm totally in for it. It will simplify greatly the whole my process and
> > will allow to do more cross-tree work.
> >
> > Can we move to pull-request model?
>
> Yes, I'm fine with that.
>
> > Thanks, it is much clear.
> > When do you expect to update your branches so we will be able to prepare our shared code?
>
> Tomorrow.  It's the weekend here.
>

Thanks

>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG Key ID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: This merge window...

[Amrani, Ram]

Hi Doug,

> > Can we move to pull-request model?
> 
> Yes, I'm fine with that.
> 

I'm in favor too.
I think this will lower overhead (on you) and speed things up.

I guess we'll need a clear process for this to work well.
E.g, refresh the branches (periodically? Once notified?), match expectations on their contents, make sure they are stable around pull time and etc.

Thanks,
Ram

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: This merge window...

[Leon Romanovsky]

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

On Tue, Jul 18, 2017 at 07:47:21AM +0000, Amrani, Ram wrote:
> Hi Doug,
>
> > > Can we move to pull-request model?
> >
> > Yes, I'm fine with that.
> >
>
> I'm in favor too.
> I think this will lower overhead (on you) and speed things up.
>
> I guess we'll need a clear process for this to work well.
> E.g, refresh the branches (periodically? Once notified?), match expectations on their contents, make sure they are stable around pull time and etc.

I think that we agreed that branches are going to be updated on constant basis.
This operation process is the same as DaveM's methodology.

I'm going to post pull-requests together with patches based on for-next Doug's tag.
https://www.mail-archive.com/netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg168151.html

The readers of this mailing list will see slightly different cover
letter, but no other changes will be (they still see and discuss over
patches posted on to the mailing list), while Doug will do something like:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-fixes-2017-05-12-V2
into his tree and will get the whole series.

So nothing to change, just update for-next, for-rc constantly and pull for-rc to for-next from time to time.

Thanks

>
> Thanks,
> Ram
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: This merge window...

[Amrani, Ram]

> I think that we agreed that branches are going to be updated on constant basis.
> This operation process is the same as DaveM's methodology.
> 
> I'm going to post pull-requests together with patches based on for-next Doug's tag.
> https://www.mail-archive.com/netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg168151.html
> 
> The readers of this mailing list will see slightly different cover
> letter, but no other changes will be (they still see and discuss over
> patches posted on to the mailing list), while Doug will do something like:
> git pull git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-fixes-2017-05-12-V2
> into his tree and will get the whole series.
> 
> So nothing to change, just update for-next, for-rc constantly and pull for-rc to for-next from time to time.
> 
> Thanks
> 

OK, thanks.

Ram

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: This merge window...

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 2020 bytes --]

On 7/18/2017 4:05 AM, Leon Romanovsky wrote:
> On Tue, Jul 18, 2017 at 07:47:21AM +0000, Amrani, Ram wrote:
>> Hi Doug,
>>
>>>> Can we move to pull-request model?
>>>
>>> Yes, I'm fine with that.
>>>
>>
>> I'm in favor too.
>> I think this will lower overhead (on you) and speed things up.
>>
>> I guess we'll need a clear process for this to work well.
>> E.g, refresh the branches (periodically? Once notified?), match expectations on their contents, make sure they are stable around pull time and etc.
> 
> I think that we agreed that branches are going to be updated on constant basis.
> This operation process is the same as DaveM's methodology.
> 
> I'm going to post pull-requests together with patches based on for-next Doug's tag.
> https://www.mail-archive.com/netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg168151.html
> 
> The readers of this mailing list will see slightly different cover
> letter, but no other changes will be (they still see and discuss over
> patches posted on to the mailing list), while Doug will do something like:
> git pull git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-fixes-2017-05-12-V2
> into his tree and will get the whole series.
> 
> So nothing to change, just update for-next, for-rc constantly and pull for-rc to for-next from time to time.

Close, but I'll pull each -rc update into for-next (which is what Dave
does too as far as I can tell).  When the for-rc lands in an -rc, it
will also land in the for-next branch.  This first week for-next branch
is not yet ready.  I'm still sorting and separating patches that I want
to put in -rc instead of -next, and when that's done, I need to rebase
-next to remove the duplicates and then when I merge -rc2 into -next all
of the -rc patches that Linus has taken will arrive.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]