rdma-core stable releases

rdma-core stable releases

[Kalderon, Michal]

Hi, 

Following EWG weekly meeting, I'd like to open a discussion regarding the necessity of maintaining a
stable rdma-core branch similar to the linux kernel stable branches. I understood there were some
offline discussions on the topic and would like to raise it on the list and try to push forward. 

We found a critical qedr bug during OFA debug event testing. We provided a patch which
was applied (e768239 libqedr: fix inline data copy). However, we remain with rdma-core-15 broken
for qedr.
 
We feel for this case, and perhaps other similar issues in the future, it will be useful and critical for distros,
OFED, and independent package-installation to have a stable release for each rdma-core release.

I'd like to here if anyone has any objects / concerns on the matter in general, and if there is a
consensus about the need and whether this is something the rdma-core maintainers would be willing
to provide. 

Thanks,
Michal 


--
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: rdma-core stable releases

[Jason Gunthorpe]

On Mon, Nov 06, 2017 at 06:21:47PM +0000, Kalderon, Michal wrote:

> I'd like to here if anyone has any objects / concerns on the matter
> in general, and if there is a consensus about the need and whether
> this is something the rdma-core maintainers would be willing to
> provide.

Previous discussions on this topic concluded that if someone wishes to
maintain a stable branch scheme then we'd make space for that (eg a
github branch or whatever).

I don't think the existing maintainers are interested in directly
working on this project, so there is room for a new volunteer!

Jason
--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Mon, Nov 06, 2017 at 11:27:56AM -0700, Jason Gunthorpe wrote:
> On Mon, Nov 06, 2017 at 06:21:47PM +0000, Kalderon, Michal wrote:
>
> > I'd like to here if anyone has any objects / concerns on the matter
> > in general, and if there is a consensus about the need and whether
> > this is something the rdma-core maintainers would be willing to
> > provide.
>
> Previous discussions on this topic concluded that if someone wishes to
> maintain a stable branch scheme then we'd make space for that (eg a
> github branch or whatever).
>
> I don't think the existing maintainers are interested in directly
> working on this project, so there is room for a new volunteer!

The offline discussion was with Vlad.
This is the quote of my latest response to him:

"There is a need to post request to the mailing list with description of
why do you need it and the volunteer name to manage it.

It should come with file in Documentation with explanation how such
stable branches are managed, for how long, if releases are going
to be done and then, ..."

Thanks

>
> Jason

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

RE: rdma-core stable releases

[Davis, Arlin R]

> > Previous discussions on this topic concluded that if someone wishes to
> > maintain a stable branch scheme then we'd make space for that (eg a
> > github branch or whatever).
> >
> > I don't think the existing maintainers are interested in directly
> > working on this project, so there is room for a new volunteer!
> 
> The offline discussion was with Vlad.
> This is the quote of my latest response to him:
> 
> "There is a need to post request to the mailing list with description of why do
> you need it and the volunteer name to manage it.
> 
> It should come with file in Documentation with explanation how such stable
> branches are managed, for how long, if releases are going to be done and
> then, ..."

We certainly see the value in a stable branch for rdma-core, especially with 
the various distro's on different release cadences. I may have a resource
that can help create and maintain this stable branch. Working on the why, 
who, and how document. In the meantime, if anyone else wants to step 
up that is also fine.

-arlin




--
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: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 06/11/2017 à 19:27, Jason Gunthorpe a écrit :
> On Mon, Nov 06, 2017 at 06:21:47PM +0000, Kalderon, Michal wrote:
>
>> I'd like to here if anyone has any objects / concerns on the matter
>> in general, and if there is a consensus about the need and whether
>> this is something the rdma-core maintainers would be willing to
>> provide.
> Previous discussions on this topic concluded that if someone wishes to
> maintain a stable branch scheme then we'd make space for that (eg a
> github branch or whatever).
>
> I don't think the existing maintainers are interested in directly
> working on this project, so there is room for a new volunteer!
>
>

I agree there is a big need for that. Currently reviewing all the patches I haven't read (only 1000 mails to go...) to see if they need to be backported on top on rdma-core 15 for the next SLES.
I'd gladly help maintaining this as I'm spending time on it anyway.
I'll leave wiser people debate and ready a doc on how this should be done though :)

Nicolas
--
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: rdma-core stable releases

[Davis, Arlin R]

> I agree there is a big need for that. Currently reviewing all the patches I haven't
> read (only 1000 mails to go...) to see if they need to be backported on top on
> rdma-core 15 for the next SLES.
> I'd gladly help maintaining this as I'm spending time on it anyway.
> I'll leave wiser people debate and ready a doc on how this should be done
> though :)
> 
> Nicolas

Thanks Nicolas. 

Ok, I am not sure what details the rdma-core maintainers are looking for in a document. Let me start the discussion with the following:

Stable Branch Release

Current Maintainer: Nicolas Morey-Chaisemartin <NMoreyChaisemartin@suse.de>

Upstream rdma-core is considered stable after each mainline release. Branched stable releases, off a mainline release, are on as-needed basis and limited to bug fixes. All bug fixes are to be backported from mainline and applied by stable branch maintainer. Branched stable releases will append an additional release number (e.g. 15.1) and will ensure that Travis CI reports a successful build.  Mention the frequency of stable releases or keep it "as is" cadence?

See versioning.md for setting package version on a stable branch.

Arlin

Re: rdma-core stable releases

[Leon Romanovsky]

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

On Fri, Nov 10, 2017 at 06:36:28PM +0000, Davis, Arlin R wrote:
> > I agree there is a big need for that. Currently reviewing all the patches I haven't
> > read (only 1000 mails to go...) to see if they need to be backported on top on
> > rdma-core 15 for the next SLES.
> > I'd gladly help maintaining this as I'm spending time on it anyway.
> > I'll leave wiser people debate and ready a doc on how this should be done
> > though :)
> >
> > Nicolas
>
> Thanks Nicolas.
>
> Ok, I am not sure what details the rdma-core maintainers are looking for in a document. Let me start the discussion with the following:

More or less, you wrote everything that I expected, just need to post it
as a patch so I can apply it to rdma-core.

The thing which is important to me is how long that stable will be maintained and how often they will be opened,
I don't want to see 12 stable branches after 3 years of running rdma-core. It releases every 2-3 months, so theoretically
we can find ourselves creating stable branches after every release (4 per year).

Thanks

>
> Stable Branch Release
>
> Current Maintainer: Nicolas Morey-Chaisemartin <NMoreyChaisemartin-l3A5Bk7waGM@public.gmane.org>
>
> Upstream rdma-core is considered stable after each mainline release. Branched stable releases, off a mainline release, are on as-needed basis and limited to bug fixes. All bug fixes are to be backported from mainline and applied by stable branch maintainer. Branched stable releases will append an additional release number (e.g. 15.1) and will ensure that Travis CI reports a successful build.  Mention the frequency of stable releases or keep it "as is" cadence?
>
> See versioning.md for setting package version on a stable branch.
>
> Arlin
>
>
>

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

Re: rdma-core stable releases

[Jason Gunthorpe]

On Fri, Nov 10, 2017 at 10:24:55PM +0200, Leon Romanovsky wrote:
> More or less, you wrote everything that I expected, just need to post it
> as a patch so I can apply it to rdma-core.

Also please describe how to get patches into -stable, eg similar to
the kernel, mark with fixes and cc the stable maintainer.

There should also be absolutely no ABI changes in the -stable branchs.

> The thing which is important to me is how long that stable will be
> maintained and how often they will be opened, I don't want to see 12
> stable branches after 3 years of running rdma-core. It releases
> every 2-3 months, so theoretically we can find ourselves creating
> stable branches after every release (4 per year).

Should be up to the people doing this, IMHO.

Ultimately I think people will settle on a couple of revisions that
ended up being used in distros, OFED, MOFED, etc.

Jason
--
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: rdma-core stable releases

[Woodruff, Robert J]

Jason wrote,

>There should also be absolutely no ABI changes in the -stable branchs.

I agree and stable branch should be for bug fixes only, new features should be only included in the master branch that is for the next major release of rdma-core.

>Ultimately I think people will settle on a couple of revisions that ended up being used in distros, OFED, MOFED, etc.

I also agree, most likely not every new rdma-core release will also need to have a stable branch. Probably just the ones that are ending up in distros. I think this is what the kernel does too,
Right ?

--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Fri, Nov 10, 2017 at 09:21:24PM +0000, Woodruff, Robert J wrote:
> Jason wrote,
>
> >There should also be absolutely no ABI changes in the -stable branchs.
>
> I agree and stable branch should be for bug fixes only, new features should be only included in the master branch that is for the next major release of rdma-core.
>
> >Ultimately I think people will settle on a couple of revisions that ended up being used in distros, OFED, MOFED, etc.
>
> I also agree, most likely not every new rdma-core release will also need to have a stable branch. Probably just the ones that are ending up in distros. I think this is what the kernel does too,
> Right ?

I'm not sure about it.
For example LTS trees are created primarily for Android [1].

Various distros take new kernel every year or two, so it limits number of stable branches.
In our case, MOFED has 6-months cycle. I don't know anything about OFED cycles.

Thanks

[1] https://lwn.net/Articles/738225/

>
> --
> 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: rdma-core stable releases

[Jason Gunthorpe]

On Sat, Nov 11, 2017 at 09:46:25AM +0200, Leon Romanovsky wrote:

> I'm not sure about it.
> For example LTS trees are created primarily for Android [1].
> 
> Various distros take new kernel every year or two, so it limits number of stable branches.
> In our case, MOFED has 6-months cycle. I don't know anything about OFED cycles.

In this case the LTS kernel process is attempting to generate
consensus downstream on what kernel version to use.. I'm not sure we
should care so much about that for RDMA.

It is best for eveyone that each downstream disto take the latest
rdma-core available when they are starting their release process and
not try and stick to some older and less featured LTS version.

Jason
--
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: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 10/11/2017 à 22:14, Jason Gunthorpe a écrit :
> On Fri, Nov 10, 2017 at 10:24:55PM +0200, Leon Romanovsky wrote:
>> More or less, you wrote everything that I expected, just need to post it
>> as a patch so I can apply it to rdma-core.
> Also please describe how to get patches into -stable, eg similar to
> the kernel, mark with fixes and cc the stable maintainer.
>
> There should also be absolutely no ABI changes in the -stable branchs.

Agreed. Ideally we would add something to CI so that it detects ABI breake on stable branches.
I know SUSE has something like this for maintenance fixes. I'll look into it.

Nicolas
--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Mon, Nov 13, 2017 at 08:01:48AM +0100, Nicolas Morey-Chaisemartin wrote:
>
>
> Le 10/11/2017 à 22:14, Jason Gunthorpe a écrit :
> > On Fri, Nov 10, 2017 at 10:24:55PM +0200, Leon Romanovsky wrote:
> >> More or less, you wrote everything that I expected, just need to post it
> >> as a patch so I can apply it to rdma-core.
> > Also please describe how to get patches into -stable, eg similar to
> > the kernel, mark with fixes and cc the stable maintainer.
> >
> > There should also be absolutely no ABI changes in the -stable branchs.
>
> Agreed. Ideally we would add something to CI so that it detects ABI breake on stable branches.
> I know SUSE has something like this for maintenance fixes. I'll look into it.

DPDK runs ABI compliance checker.
http://ispras.linuxbase.org/index.php/ABI_compliance_checker

I would love to see it running for rdma-core.

Thanks

>
> Nicolas

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

Re: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 13/11/2017 à 08:08, Leon Romanovsky a écrit :
> On Mon, Nov 13, 2017 at 08:01:48AM +0100, Nicolas Morey-Chaisemartin wrote: >> >> >> Le 10/11/2017 à 22:14, Jason Gunthorpe a écrit : >>> On Fri, Nov 10, 2017 at 10:24:55PM +0200, Leon Romanovsky wrote: >>>> More or less, you wrote everything that I expected, just need to post it >>>> as a patch so I can apply it to rdma-core. >>> Also please describe how to get patches into -stable, eg similar to >>> the kernel, mark with fixes and cc the stable maintainer. >>> >>> There should also be absolutely no ABI changes in the -stable branchs. >> >> Agreed. Ideally we would add something to CI so that it detects ABI breake on stable branches. >> I know SUSE has something like this for maintenance fixes. I'll look into it. > > DPDK runs ABI compliance checker. > http://ispras.linuxbase.org/index.
 php/ABI_compliance_checker > > I would love to see it running for rdma-core. > > Thanks > >
The only issue I can foresee with these is that we need to run the ABI checker on both the "old" and "new" versions.
We would probably need to do something at release time to generate and publish the ABI xml file somewhere (either in the repo, or github) so that we can check against it later without recompiling it.

Nicolas

--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Mon, Nov 13, 2017 at 08:18:02AM +0100, Nicolas Morey-Chaisemartin wrote:
>
>
> Le 13/11/2017 à 08:08, Leon Romanovsky a écrit :
> > On Mon, Nov 13, 2017 at 08:01:48AM +0100, Nicolas Morey-Chaisemartin wrote: >> >> >> Le 10/11/2017 à 22:14, Jason Gunthorpe a écrit : >>> On Fri, Nov 10, 2017 at 10:24:55PM +0200, Leon Romanovsky wrote: >>>> More or less, you wrote everything that I expected, just need to post it >>>> as a patch so I can apply it to rdma-core. >>> Also please describe how to get patches into -stable, eg similar to >>> the kernel, mark with fixes and cc the stable maintainer. >>> >>> There should also be absolutely no ABI changes in the -stable branchs. >> >> Agreed. Ideally we would add something to CI so that it detects ABI breake on stable branches. >> I know SUSE has something like this for maintenance fixes. I'll look into it. > > DPDK runs ABI compliance checker. > http://ispras.linuxbase.org/index.php/ABI_compliance_checker > > I would love to see it running for rdma-core. > > Thanks > >
> The only issue I can foresee with these is that we need to run the ABI checker on both the "old" and "new" versions.
> We would probably need to do something at release time to generate and publish the ABI xml file somewhere (either in the repo, or github) so that we can check against it later without recompiling it.

We can publish it together with released files in github release section.

Thanks

>
> Nicolas
>

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

Re: rdma-core stable releases

[Jason Gunthorpe]

On Mon, Nov 13, 2017 at 08:18:02AM +0100, Nicolas Morey-Chaisemartin wrote:

> The only issue I can foresee with these is that we need to run the
> ABI checker on both the "old" and "new" versions.  We would probably
> need to do something at release time to generate and publish the ABI
> xml file somewhere (either in the repo, or github) so that we can
> check against it later without recompiling it.

When you start the stable branch you can include the reference ABI
output as the first commit.

Jaason
--
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: rdma-core stable releases

[Amrani, Ram]

> DPDK runs ABI compliance checker.
> http://ispras.linuxbase.org/index.php/ABI_compliance_checker
> 
> I would love to see it running for rdma-core.
> 
> Thanks
> 
> >
> > Nicolas

It is logical that ABI version changes won't be supported. As well as new features that affect the ABI.
Still, I would like to have the following fix ability - 
Use a bit in an existing u32, via adding an entry to an existing enum.
I can imagine this being used as a feature disable/enable.

What do you consider as an "ABI change"?

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: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 13/11/2017 à 09:47, Amrani, Ram a écrit :
>> DPDK runs ABI compliance checker.
>> http://ispras.linuxbase.org/index.php/ABI_compliance_checker
>>
>> I would love to see it running for rdma-core.
>>
>> Thanks
>>
>>> Nicolas
> It is logical that ABI version changes won't be supported. As well as new features that affect the ABI.
> Still, I would like to have the following fix ability - 
> Use a bit in an existing u32, via adding an entry to an existing enum.
> I can imagine this being used as a feature disable/enable.
>
> What do you consider as an "ABI change"?
>
> Thanks,
> Ram

When I mean no ABI changes I mean that anything compiled against rdma-core X.Y also compiles (and and run without recompiling) against X.Z with Z >= Y.
This is very important for distro maintenance. You cannot break your user code just to add a fix.

Your request should be compatible BUT, it may create some more difficulties for rdma-core users.
Basically I don't want developers to have to fill their code with ifdefs code to deal with all the versions of stable releases.

So let's say no to your request by default, but if you have a very good reason and it's the most sensible way to fix an issue, I'll be open to discussion ;)

Nicolas

--
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: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 13/11/2017 à 10:04, Nicolas Morey-Chaisemartin a écrit :
>
> Le 13/11/2017 à 09:47, Amrani, Ram a écrit :
>>> DPDK runs ABI compliance checker.
>>> http://ispras.linuxbase.org/index.php/ABI_compliance_checker
>>>
>>> I would love to see it running for rdma-core.
>>>
>>> Thanks
>>>
>>>> Nicolas
>> It is logical that ABI version changes won't be supported. As well as new features that affect the ABI.
>> Still, I would like to have the following fix ability - 
>> Use a bit in an existing u32, via adding an entry to an existing enum.
>> I can imagine this being used as a feature disable/enable.
>>
>> What do you consider as an "ABI change"?
>>
>> Thanks,
>> Ram
> When I mean no ABI changes I mean that anything compiled against rdma-core X.Y also compiles (and and run without recompiling) against X.Z with Z >= Y.
> This is very important for distro maintenance. You cannot break your user code just to add a fix.
>
> Your request should be compatible BUT, it may create some more difficulties for rdma-core users.
> Basically I don't want developers to have to fill their code with ifdefs code to deal with all the versions of stable releases.
>
> So let's say no to your request by default, but if you have a very good reason and it's the most sensible way to fix an issue, I'll be open to discussion ;)
>
> Nicolas
>
> --
> 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

I'm guessing your concern is for this patch:
    verbs: Do not block QP attr_masks used by older kernels

The new bits could be accepted.
But as the new enum values have 0 effect (the fix in itself is just the first two hunks that change the bitmask computations), it'd be better to resubmit the patch without the new bits for the stable branch.
--
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: rdma-core stable releases

[Amrani, Ram]

> I'm guessing your concern is for this patch:
>     verbs: Do not block QP attr_masks used by older kernels
> 
> The new bits could be accepted.
> But as the new enum values have 0 effect (the fix in itself is just the first two hunks that change the bitmask computations), it'd
> be better to resubmit the patch without the new bits for the stable branch.

I had something else in mind, that is not yet relevant to upstream.
As for this patch, I'd take the comments. They bear importance as well.

Ram

RE: rdma-core stable releases

[Amrani, Ram]

> When I mean no ABI changes I mean that anything compiled against rdma-core X.Y also compiles (and and run without
> recompiling) against X.Z with Z >= Y.
> This is very important for distro maintenance. You cannot break your user code just to add a fix.

"compiled against" implies an application.
We are talking about the kernel/user ABI as well, right?

> Your request should be compatible BUT, it may create some more difficulties for rdma-core users.
> Basically I don't want developers to have to fill their code with ifdefs code to deal with all the versions of stable releases.

I don't intend any 'ifedefs' in these kinds of fixes. This isn't really backward compatible

> So let's say no to your request by default, but if you have a very good reason and it's the most sensible way to fix an issue, I'll be
> open to discussion ;)

OK

Ram

Re: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 13/11/2017 à 11:11, Amrani, Ram a écrit :
>> When I mean no ABI changes I mean that anything compiled against rdma-core X.Y also compiles (and and run without
>> recompiling) against X.Z with Z >= Y.
>> This is very important for distro maintenance. You cannot break your user code just to add a fix.
> "compiled against" implies an application.
> We are talking about the kernel/user ABI as well, right?

I was talking about the application side of things.
For the kernel side, any rdma-core version is supposed to work against any kernel so as long as it's still true after applying the fix, I don't see much of a risk there.

Nicolas
--
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: rdma-core stable releases

[Amrani, Ram]

> Le 13/11/2017 à 11:11, Amrani, Ram a écrit :
> >> When I mean no ABI changes I mean that anything compiled against rdma-core X.Y also compiles (and and run without
> >> recompiling) against X.Z with Z >= Y.
> >> This is very important for distro maintenance. You cannot break your user code just to add a fix.
> > "compiled against" implies an application.
> > We are talking about the kernel/user ABI as well, right?
> 
> I was talking about the application side of things.
> For the kernel side, any rdma-core version is supposed to work against any kernel so as long as it's still true after applying the fix,
> I don't see much of a risk there.
> 
> Nicolas

OK

Re: rdma-core stable releases

[Jason Gunthorpe]

On Mon, Nov 13, 2017 at 08:47:10AM +0000, Amrani, Ram wrote:

> It is logical that ABI version changes won't be supported. As well as new features that affect the ABI.
> Still, I would like to have the following fix ability - 
> Use a bit in an existing u32, via adding an entry to an existing enum.
> I can imagine this being used as a feature disable/enable.

No.

No ABI change means no new symbols in the public header files, no
changes in manual pages and no 'backwards compatible' changes. No
ABI changes at all.

Only mainline can have ABI changes, and the -stable should be
completely compatible up and down all stable releases. Compiling
against 15.9 should continue to load and work with the same feature
set 100%.

Anything else is madness and people will start to ask for backpointing
features and other crazy things to -stable.

Jason
--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Mon, Nov 13, 2017 at 12:13:11PM -0700, Jason Gunthorpe wrote:
> On Mon, Nov 13, 2017 at 08:47:10AM +0000, Amrani, Ram wrote:
>
> > It is logical that ABI version changes won't be supported. As well as new features that affect the ABI.
> > Still, I would like to have the following fix ability -
> > Use a bit in an existing u32, via adding an entry to an existing enum.
> > I can imagine this being used as a feature disable/enable.
>
> No.
>
> No ABI change means no new symbols in the public header files, no
> changes in manual pages and no 'backwards compatible' changes. No
> ABI changes at all.
>
> Only mainline can have ABI changes, and the -stable should be
> completely compatible up and down all stable releases. Compiling
> against 15.9 should continue to load and work with the same feature
> set 100%.

+1
This is the whole idea of -stable branch.

>
> Anything else is madness and people will start to ask for backpointing
> features and other crazy things to -stable.
>
> Jason

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

Re: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 13/11/2017 à 08:08, Leon Romanovsky a écrit :
> On Mon, Nov 13, 2017 at 08:01:48AM +0100, Nicolas Morey-Chaisemartin wrote: >> >> >> Le 10/11/2017 à 22:14, Jason Gunthorpe a écrit : >>> On Fri, Nov 10, 2017 at 10:24:55PM +0200, Leon Romanovsky wrote: >>>> More or less, you wrote everything that I expected, just need to post it >>>> as a patch so I can apply it to rdma-core. >>> Also please describe how to get patches into -stable, eg similar to >>> the kernel, mark with fixes and cc the stable maintainer. >>> >>> There should also be absolutely no ABI changes in the -stable branchs. >> >> Agreed. Ideally we would add something to CI so that it detects ABI breake on stable branches. >> I know SUSE has something like this for maintenance fixes. I'll look into it. > > DPDK runs ABI compliance checker. > http://ispras.linuxbase.org/index.
 php/ABI_compliance_checker > > I would love to see it running for rdma-core. > > Thanks >
Got the scripts ready for this BUT the versions available in docker of abi-dump/abi-compliance-checker are not compatible.
As both are GPLv2, could I import them into buildlib ?

Nicolas

--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Tue, Nov 14, 2017 at 11:27:40AM +0100, Nicolas Morey-Chaisemartin wrote:
>
>
> Le 13/11/2017 à 08:08, Leon Romanovsky a écrit :
> > On Mon, Nov 13, 2017 at 08:01:48AM +0100, Nicolas Morey-Chaisemartin wrote: >> >> >> Le 10/11/2017 à 22:14, Jason Gunthorpe a écrit : >>> On Fri, Nov 10, 2017 at 10:24:55PM +0200, Leon Romanovsky wrote: >>>> More or less, you wrote everything that I expected, just need to post it >>>> as a patch so I can apply it to rdma-core. >>> Also please describe how to get patches into -stable, eg similar to >>> the kernel, mark with fixes and cc the stable maintainer. >>> >>> There should also be absolutely no ABI changes in the -stable branchs. >> >> Agreed. Ideally we would add something to CI so that it detects ABI breake on stable branches. >> I know SUSE has something like this for maintenance fixes. I'll look into it. > > DPDK runs ABI compliance checker. > http://ispras.linuxbase.org/index.php/ABI_compliance_checker > > I would love to see it running for rdma-core. > > Thanks >
> Got the scripts ready for this BUT the versions available in docker of abi-dump/abi-compliance-checker are not compatible.
> As both are GPLv2, could I import them into buildlib ?

I'm not a lawyer,
Our dual license policy is relevant for source code and build scripts only. The tools for our CI can be GPLv2-only.

Thanks

>
> Nicolas
>

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

Re: rdma-core stable releases

[Jason Gunthorpe]

On Tue, Nov 14, 2017 at 01:05:58PM +0200, Leon Romanovsky wrote:
> On Tue, Nov 14, 2017 at 11:27:40AM +0100, Nicolas Morey-Chaisemartin wrote:
> >
> >
> > Le 13/11/2017 à 08:08, Leon Romanovsky a écrit :
> > > On Mon, Nov 13, 2017 at 08:01:48AM +0100, Nicolas Morey-Chaisemartin wrote: >> >> >> Le 10/11/2017 à 22:14, Jason Gunthorpe a écrit : >>> On Fri, Nov 10, 2017 at 10:24:55PM +0200, Leon Romanovsky wrote: >>>> More or less, you wrote everything that I expected, just need to post it >>>> as a patch so I can apply it to rdma-core. >>> Also please describe how to get patches into -stable, eg similar to >>> the kernel, mark with fixes and cc the stable maintainer. >>> >>> There should also be absolutely no ABI changes in the -stable branchs. >> >> Agreed. Ideally we would add something to CI so that it detects ABI breake on stable branches. >> I know SUSE has something like this for maintenance fixes. I'll look into it. > > DPDK runs ABI compliance checker. > http://ispras.linuxbase.org/
 index.php/ABI_compliance_checker > > I would love to see it running for rdma-core. > > Thanks >
> > Got the scripts ready for this BUT the versions available in docker of abi-dump/abi-compliance-checker are not compatible.
> > As both are GPLv2, could I import them into buildlib ?
> 
> I'm not a lawyer, Our dual license policy is relevant for source
> code and build scripts only. The tools for our CI can be GPLv2-only.

Right, but it is very important that any important code come with the
right license files in COPYING.* so you'd have to at least add
COPYING.LGPL and update debian/copyright and COPYING.md

The files look small enough that we could choose to include them in
buildlib.

Jason
--
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: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 10/11/2017 à 21:24, Leon Romanovsky a écrit :
> On Fri, Nov 10, 2017 at 06:36:28PM +0000, Davis, Arlin R wrote: >>> I agree there is a big need for that. Currently reviewing all the patches I haven't >>> read (only 1000 mails to go...) to see if they need to be backported on top on >>> rdma-core 15 for the next SLES. >>> I'd gladly help maintaining this as I'm spending time on it anyway. >>> I'll leave wiser people debate and ready a doc on how this should be done >>> though :) >>> >>> Nicolas >> >> Thanks Nicolas. >> >> Ok, I am not sure what details the rdma-core maintainers are looking for in a document. Let me start the discussion with the following: > > More or less, you wrote everything that I expected, just need to post it > as a patch so I can apply it to rdma-core. > > The thing which is important to me is how long that stabl
 e will be maintained and how often they will be opened, > I don't want to see 12 stable branches after 3 years of running rdma-core. It releases every 2-3 months, so theoretically > we can find ourselves creating stable branches after every release (4 per
year). > > Thanks > >> >> Stable Branch Release >> >> Current Maintainer: Nicolas Morey-Chaisemartin <NMoreyChaisemartin-l3A5Bk7waGM@public.gmane.org> >> >> Upstream rdma-core is considered stable after each mainline release. Branched stable releases, off a mainline release, are on as-needed basis and limited to bug fixes. All bug fixes are to be backported from mainline and applied by stable branch maintainer. Branched stable releases will append an additional release number (e.g. 15.1) and will ensure that Travis CI reports a successful build.  Mention the frequency of stable releases or keep it "as is" cadence? >> >> See versioning.md for setting package version on a stable branch. >> >> Arlin >> >> >>
What would make sense IMHO would be to have people submit their patches to stable branches through a github issues.
Each issue should be tagged in all the main/stable release it is in and contains a SHA1 to a patch from master that contains a fix.

- Allows to have a clear picture of what's broken/what's fixed for each release
- Creating a stable branch becomes easier  (If any distro asks for a stable branch from a couple release ago, just take the bug list apply all the patches and you should be good to go)
- Avoid multiple PR/patches for a patch that needs to be included into multiple stable branches

Concerning how long stable branch will be maintained, it will probably make sense to have some LTS branches and other shorter ones.
Distros branches will probably need to have LTS support (RHEL and SLE have several years of support without ABI breakage that it make sense to do upstream).
Other branches should only last until release N+1 (or N+2) .

This reduces the number of branch to maintain to the "few" distro use and provide fixed version of the latest for every day user that do not want the bleeding edge master.

Nicolas


--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Mon, Nov 13, 2017 at 08:14:03AM +0100, Nicolas Morey-Chaisemartin wrote:
>
>
> Le 10/11/2017 à 21:24, Leon Romanovsky a écrit :
> > On Fri, Nov 10, 2017 at 06:36:28PM +0000, Davis, Arlin R wrote: >>> I agree there is a big need for that. Currently reviewing all the patches I haven't >>> read (only 1000 mails to go...) to see if they need to be backported on top on >>> rdma-core 15 for the next SLES. >>> I'd gladly help maintaining this as I'm spending time on it anyway. >>> I'll leave wiser people debate and ready a doc on how this should be done >>> though :) >>> >>> Nicolas >> >> Thanks Nicolas. >> >> Ok, I am not sure what details the rdma-core maintainers are looking for in a document. Let me start the discussion with the following: > > More or less, you wrote everything that I expected, just need to post it > as a patch so I can apply it to rdma-core. > > The thing which is important to me is how long that stable will be maintained and how often they will be opened, > I don't want to see 12 stable branches after 3 years of running rdma-core. It releases every 2-3 months, so theoretically > we can find ourselves creating stable branches after every release (4 per
> year). > > Thanks > >> >> Stable Branch Release >> >> Current Maintainer: Nicolas Morey-Chaisemartin <NMoreyChaisemartin-l3A5Bk7waGM@public.gmane.org> >> >> Upstream rdma-core is considered stable after each mainline release. Branched stable releases, off a mainline release, are on as-needed basis and limited to bug fixes. All bug fixes are to be backported from mainline and applied by stable branch maintainer. Branched stable releases will append an additional release number (e.g. 15.1) and will ensure that Travis CI reports a successful build.  Mention the frequency of stable releases or keep it "as is" cadence? >> >> See versioning.md for setting package version on a stable branch. >> >> Arlin >> >> >>
> What would make sense IMHO would be to have people submit their patches to stable branches through a github issues.
> Each issue should be tagged in all the main/stable release it is in and contains a SHA1 to a patch from master that contains a fix.

Nicolas,
Something went wrong with your mailer, It created long lines and broke lines.
Can you please resend so we will be able to read it?

Thanks

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

Re: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 10/11/2017 à 21:24, Leon Romanovsky a écrit :
> On Fri, Nov 10, 2017 at 06:36:28PM +0000, Davis, Arlin R wrote:
>>> I agree there is a big need for that. Currently reviewing all the patches I haven't
>>> read (only 1000 mails to go...) to see if they need to be backported on top on
>>> rdma-core 15 for the next SLES.
>>> I'd gladly help maintaining this as I'm spending time on it anyway.
>>> I'll leave wiser people debate and ready a doc on how this should be done
>>> though :)
>>>
>>> Nicolas
>> Thanks Nicolas.
>>
>> Ok, I am not sure what details the rdma-core maintainers are looking for in a document. Let me start the discussion with the following:
> More or less, you wrote everything that I expected, just need to post it
> as a patch so I can apply it to rdma-core.
>
> The thing which is important to me is how long that stable will be maintained and how often they will be opened,
> I don't want to see 12 stable branches after 3 years of running rdma-core. It releases every 2-3 months, so theoretically
> we can find ourselves creating stable branches after every release (4 per year).
>
> Thanks
>
>> Stable Branch Release
>>
>> Current Maintainer: Nicolas Morey-Chaisemartin <NMoreyChaisemartin-l3A5Bk7waGM@public.gmane.org>
>>
>> Upstream rdma-core is considered stable after each mainline release. Branched stable releases, off a mainline release, are on as-needed basis and limited to bug fixes. All bug fixes are to be backported from mainline and applied by stable branch maintainer. Branched stable releases will append an additional release number (e.g. 15.1) and will ensure that Travis CI reports a successful build.  Mention the frequency of stable releases or keep it "as is" cadence?
>>
>> See versioning.md for setting package version on a stable branch.
>>
>> Arlin
>>
>>
>>


Resent because Thunderbird screwed up my content.


What would make sense IMHO would be to have people submit their patches to stable branches through a github issues.
Each issue should be tagged in all the main/stable release it is in and contains a SHA1 to a patch from master that contains a fix.

- Allows to have a clear picture of what's broken/what's fixed for each release
- Creating a stable branch becomes easier  (If any distro asks for a stable branch from a couple release ago, just take the bug list apply all the patches and you should be good to go)
- Avoid multiple PR/patches for a patch that needs to be included into multiple stable branches

Concerning how long stable branch will be maintained, it will probably make sense to have some LTS branches and other shorter ones.
Distros branches will probably need to have LTS support (RHEL and SLE have several years of support without ABI breakage that it make sense to do upstream).
Other branches should only last until release N+1 (or N+2) .

This reduces the number of branch to maintain to the "few" distro use and provide fixed version of the latest for every day user that do not want the bleeding edge master.

Nicolas

--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Mon, Nov 13, 2017 at 08:53:19AM +0100, Nicolas Morey-Chaisemartin wrote:
>
>
> Le 10/11/2017 à 21:24, Leon Romanovsky a écrit :
> > On Fri, Nov 10, 2017 at 06:36:28PM +0000, Davis, Arlin R wrote:
> >>> I agree there is a big need for that. Currently reviewing all the patches I haven't
> >>> read (only 1000 mails to go...) to see if they need to be backported on top on
> >>> rdma-core 15 for the next SLES.
> >>> I'd gladly help maintaining this as I'm spending time on it anyway.
> >>> I'll leave wiser people debate and ready a doc on how this should be done
> >>> though :)
> >>>
> >>> Nicolas
> >> Thanks Nicolas.
> >>
> >> Ok, I am not sure what details the rdma-core maintainers are looking for in a document. Let me start the discussion with the following:
> > More or less, you wrote everything that I expected, just need to post it
> > as a patch so I can apply it to rdma-core.
> >
> > The thing which is important to me is how long that stable will be maintained and how often they will be opened,
> > I don't want to see 12 stable branches after 3 years of running rdma-core. It releases every 2-3 months, so theoretically
> > we can find ourselves creating stable branches after every release (4 per year).
> >
> > Thanks
> >
> >> Stable Branch Release
> >>
> >> Current Maintainer: Nicolas Morey-Chaisemartin <NMoreyChaisemartin@suse.de>
> >>
> >> Upstream rdma-core is considered stable after each mainline release. Branched stable releases, off a mainline release, are on as-needed basis and limited to bug fixes. All bug fixes are to be backported from mainline and applied by stable branch maintainer. Branched stable releases will append an additional release number (e.g. 15.1) and will ensure that Travis CI reports a successful build.  Mention the frequency of stable releases or keep it "as is" cadence?
> >>
> >> See versioning.md for setting package version on a stable branch.
> >>
> >> Arlin
> >>
> >>
> >>
>
>
> Resent because Thunderbird screwed up my content.
>
>
> What would make sense IMHO would be to have people submit their patches to stable branches through a github issues.
> Each issue should be tagged in all the main/stable release it is in and contains a SHA1 to a patch from master that contains a fix.
>

I personally against such close integration with github and creating two
different places for communication (ML and github), but as Jason said,
the core team has no plans to manage it and it will be your decision on
how you will manage it.

Right now, the gihtub issues are disabled in rdma-core, because we
didn't want people open bug reports there instead of posting to the ML.

Thanks

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

Re: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 13/11/2017 à 09:14, Leon Romanovsky a écrit :
> On Mon, Nov 13, 2017 at 08:53:19AM +0100, Nicolas Morey-Chaisemartin wrote:
>>
>> What would make sense IMHO would be to have people submit their patches to stable branches through a github issues.
>> Each issue should be tagged in all the main/stable release it is in and contains a SHA1 to a patch from master that contains a fix.
>>
> I personally against such close integration with github and creating two
> different places for communication (ML and github), but as Jason said,
> the core team has no plans to manage it and it will be your decision on
> how you will manage it.
>
> Right now, the gihtub issues are disabled in rdma-core, because we
> didn't want people open bug reports there instead of posting to the ML.
>
> Thanks


I just saw that on Github. And yes people will open bug for master there.
I don't want to intrude in  your workflow..

I'm OK with keeping just the ML for the moment. If it becomes too much of a mess, I'll come back with my github request (or something else).
How do you suggest flagging me for those patches ? Should we follow the kernel stable process ?
Meaning either:
- CC me with version information on a submission to master
- Send a mail to ML + me after patch has been accepted in master with a tag like [PATCH rdma-core stable], a list of patch-id from master, the version they apply to and why they should be picked

Do you have any request/idea/suggestion about the release rate of the stable branch ?

Nicolas
--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Mon, Nov 13, 2017 at 10:16:32AM +0100, Nicolas Morey-Chaisemartin wrote:
>
>
> Le 13/11/2017 à 09:14, Leon Romanovsky a écrit :
> > On Mon, Nov 13, 2017 at 08:53:19AM +0100, Nicolas Morey-Chaisemartin wrote:
> >>
> >> What would make sense IMHO would be to have people submit their patches to stable branches through a github issues.
> >> Each issue should be tagged in all the main/stable release it is in and contains a SHA1 to a patch from master that contains a fix.
> >>
> > I personally against such close integration with github and creating two
> > different places for communication (ML and github), but as Jason said,
> > the core team has no plans to manage it and it will be your decision on
> > how you will manage it.
> >
> > Right now, the gihtub issues are disabled in rdma-core, because we
> > didn't want people open bug reports there instead of posting to the ML.
> >
> > Thanks
>
>
> I just saw that on Github. And yes people will open bug for master there.
> I don't want to intrude in  your workflow..

Feel free "to intrude", I'm not alone here.

>
> I'm OK with keeping just the ML for the moment. If it becomes too much of a mess, I'll come back with my github request (or something else).
> How do you suggest flagging me for those patches ? Should we follow the kernel stable process ?

I think so, the kernel process works, we just need to adapt it to rdma-core.
Regarding the flagging procedure, we can do like Greg and Sasha do.

Open email account (e.g. stable-Xl5UnYtxxKxKUA01WzcqbQ@public.gmane.org), connect it to /dev/null,
so people won't get bounce emails while they sent patches to it, and
once a week or two run script [1], which will check master branch and
cherry-pick patches with Cc: stable@ in their commit messages.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/sashal/stable-tools.git/tree/


> Meaning either:
> - CC me with version information on a submission to master
> - Send a mail to ML + me after patch has been accepted in master with a tag like [PATCH rdma-core stable], a list of patch-id from master, the version they apply to and why they should be picked
>
> Do you have any request/idea/suggestion about the release rate of the stable branch ?

I don't have.

>
> Nicolas

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

Re: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 13/11/2017 à 11:41, Leon Romanovsky a écrit :
> On Mon, Nov 13, 2017 at 10:16:32AM +0100, Nicolas Morey-Chaisemartin wrote:
>>
>> Le 13/11/2017 à 09:14, Leon Romanovsky a écrit :
>>> On Mon, Nov 13, 2017 at 08:53:19AM +0100, Nicolas Morey-Chaisemartin wrote:
>>>> What would make sense IMHO would be to have people submit their patches to stable branches through a github issues.
>>>> Each issue should be tagged in all the main/stable release it is in and contains a SHA1 to a patch from master that contains a fix.
>>>>
>>> I personally against such close integration with github and creating two
>>> different places for communication (ML and github), but as Jason said,
>>> the core team has no plans to manage it and it will be your decision on
>>> how you will manage it.
>>>
>>> Right now, the gihtub issues are disabled in rdma-core, because we
>>> didn't want people open bug reports there instead of posting to the ML.
>>>
>>> Thanks
>>
>> I just saw that on Github. And yes people will open bug for master there.
>> I don't want to intrude in  your workflow..
> Feel free "to intrude", I'm not alone here.

Well from my review of v15, the amount of work at the moment seems very reasonable.
So I dont think there is a need to intrude ... yet !
>
>> I'm OK with keeping just the ML for the moment. If it becomes too much of a mess, I'll come back with my github request (or something else).
>> How do you suggest flagging me for those patches ? Should we follow the kernel stable process ?
> I think so, the kernel process works, we just need to adapt it to rdma-core.
> Regarding the flagging procedure, we can do like Greg and Sasha do.
>
> Open email account (e.g. stable-Xl5UnYtxxKxKUA01WzcqbQ@public.gmane.org), connect it to /dev/null,
> so people won't get bounce emails while they sent patches to it, and
> once a week or two run script [1], which will check master branch and
> cherry-pick patches with Cc: stable@ in their commit messages.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/sashal/stable-tools.git/tree/

Sounds fine to me.

>> Meaning either:
>> - CC me with version information on a submission to master
>> - Send a mail to ML + me after patch has been accepted in master with a tag like [PATCH rdma-core stable], a list of patch-id from master, the version they apply to and why they should be picked
>>
>> Do you have any request/idea/suggestion about the release rate of the stable branch ?
> I don't have.

Apart from distros, are there people interested in stable branches ?
If not, we could release simply release around the same time a new main release comes out (N.1 comes out at the same time as N+1.0), and on-demand when a distro requires it.

Nicolas


--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Mon, Nov 13, 2017 at 11:56:19AM +0100, Nicolas Morey-Chaisemartin wrote:
>
>
> Le 13/11/2017 à 11:41, Leon Romanovsky a écrit :
> > On Mon, Nov 13, 2017 at 10:16:32AM +0100, Nicolas Morey-Chaisemartin wrote:
> >>
> >> Le 13/11/2017 à 09:14, Leon Romanovsky a écrit :
> >>> On Mon, Nov 13, 2017 at 08:53:19AM +0100, Nicolas Morey-Chaisemartin wrote:
> >>>> What would make sense IMHO would be to have people submit their patches to stable branches through a github issues.
> >>>> Each issue should be tagged in all the main/stable release it is in and contains a SHA1 to a patch from master that contains a fix.
> >>>>
> >>> I personally against such close integration with github and creating two
> >>> different places for communication (ML and github), but as Jason said,
> >>> the core team has no plans to manage it and it will be your decision on
> >>> how you will manage it.
> >>>
> >>> Right now, the gihtub issues are disabled in rdma-core, because we
> >>> didn't want people open bug reports there instead of posting to the ML.
> >>>
> >>> Thanks
> >>
> >> I just saw that on Github. And yes people will open bug for master there.
> >> I don't want to intrude in  your workflow..
> > Feel free "to intrude", I'm not alone here.
>
> Well from my review of v15, the amount of work at the moment seems very reasonable.
> So I dont think there is a need to intrude ... yet !
> >
> >> I'm OK with keeping just the ML for the moment. If it becomes too much of a mess, I'll come back with my github request (or something else).
> >> How do you suggest flagging me for those patches ? Should we follow the kernel stable process ?
> > I think so, the kernel process works, we just need to adapt it to rdma-core.
> > Regarding the flagging procedure, we can do like Greg and Sasha do.
> >
> > Open email account (e.g. stable-Xl5UnYtxxKxKUA01WzcqbQ@public.gmane.org), connect it to /dev/null,
> > so people won't get bounce emails while they sent patches to it, and
> > once a week or two run script [1], which will check master branch and
> > cherry-pick patches with Cc: stable@ in their commit messages.
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/sashal/stable-tools.git/tree/
>
> Sounds fine to me.

Need to document that.
BTW: I opened stable-Xl5UnYtxxKxKUA01WzcqbQ@public.gmane.org email, if you want I can forward all
emails from that account to you, right now, everything goes to /dev/null.

Thanks

>
> >> Meaning either:
> >> - CC me with version information on a submission to master
> >> - Send a mail to ML + me after patch has been accepted in master with a tag like [PATCH rdma-core stable], a list of patch-id from master, the version they apply to and why they should be picked
> >>
> >> Do you have any request/idea/suggestion about the release rate of the stable branch ?
> > I don't have.
>
> Apart from distros, are there people interested in stable branches ?
> If not, we could release simply release around the same time a new main release comes out (N.1 comes out at the same time as N+1.0), and on-demand when a distro requires it.
>
> Nicolas
>
>

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

Re: rdma-core stable releases

[Nicolas Morey-Chaisemartin]

Le 13/11/2017 à 12:43, Leon Romanovsky a écrit :
> On Mon, Nov 13, 2017 at 11:56:19AM +0100, Nicolas Morey-Chaisemartin wrote:
>>
>> Le 13/11/2017 à 11:41, Leon Romanovsky a écrit :
>>
>>>> I'm OK with keeping just the ML for the moment. If it becomes too much of a mess, I'll come back with my github request (or something else).
>>>> How do you suggest flagging me for those patches ? Should we follow the kernel stable process ?
>>> I think so, the kernel process works, we just need to adapt it to rdma-core.
>>> Regarding the flagging procedure, we can do like Greg and Sasha do.
>>>
>>> Open email account (e.g. stable-Xl5UnYtxxKxKUA01WzcqbQ@public.gmane.org), connect it to /dev/null,
>>> so people won't get bounce emails while they sent patches to it, and
>>> once a week or two run script [1], which will check master branch and
>>> cherry-pick patches with Cc: stable@ in their commit messages.
>>>
>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/sashal/stable-tools.git/tree/
>> Sounds fine to me.
> Need to document that.
> BTW: I opened stable-Xl5UnYtxxKxKUA01WzcqbQ@public.gmane.org email, if you want I can forward all
> emails from that account to you, right now, everything goes to /dev/null.
>
> Thanks
>
>

Yes you can forward them to me.
I need to prepare a patch with Arlin proposal and this stuff too.

Thanks

Nicolas
--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Mon, Nov 13, 2017 at 12:44:51PM +0100, Nicolas Morey-Chaisemartin wrote:
>
>
> Le 13/11/2017 à 12:43, Leon Romanovsky a écrit :
> > On Mon, Nov 13, 2017 at 11:56:19AM +0100, Nicolas Morey-Chaisemartin wrote:
> >>
> >> Le 13/11/2017 à 11:41, Leon Romanovsky a écrit :
> >>
> >>>> I'm OK with keeping just the ML for the moment. If it becomes too much of a mess, I'll come back with my github request (or something else).
> >>>> How do you suggest flagging me for those patches ? Should we follow the kernel stable process ?
> >>> I think so, the kernel process works, we just need to adapt it to rdma-core.
> >>> Regarding the flagging procedure, we can do like Greg and Sasha do.
> >>>
> >>> Open email account (e.g. stable-Xl5UnYtxxKxKUA01WzcqbQ@public.gmane.org), connect it to /dev/null,
> >>> so people won't get bounce emails while they sent patches to it, and
> >>> once a week or two run script [1], which will check master branch and
> >>> cherry-pick patches with Cc: stable@ in their commit messages.
> >>>
> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/sashal/stable-tools.git/tree/
> >> Sounds fine to me.
> > Need to document that.
> > BTW: I opened stable-Xl5UnYtxxKxKUA01WzcqbQ@public.gmane.org email, if you want I can forward all
> > emails from that account to you, right now, everything goes to /dev/null.
> >
> > Thanks
> >
> >
>
> Yes you can forward them to me.

Done, it will take a couple of hours till it will propagate.

Thanks

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

Re: rdma-core stable releases

[Jason Gunthorpe]

On Mon, Nov 13, 2017 at 11:56:19AM +0100, Nicolas Morey-Chaisemartin wrote:

> >> Meaning either:
> >> - CC me with version information on a submission to master
> >> - Send a mail to ML + me after patch has been accepted in master with a tag like [PATCH rdma-core stable], a list of patch-id from master, the version they apply to and why they should be picked
> >>
> >> Do you have any request/idea/suggestion about the release rate of the stable branch ?
> > I don't have.
> 
> Apart from distros, are there people interested in stable branches ?
> If not, we could release simply release around the same time a new
> main release comes out (N.1 comes out at the same time as N+1.0),
> and on-demand when a distro requires it.

I'd just do it on demand.. Maybe a week after the last patch was accepted
or something. No sense in waiting for anything else. The goal here
should be to push the stable updates into the distros as quickly as
possible.

Jason
--
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: rdma-core stable releases

[Jason Gunthorpe]

On Mon, Nov 13, 2017 at 10:14:55AM +0200, Leon Romanovsky wrote:

> > What would make sense IMHO would be to have people submit their
> > patches to stable branches through a github issues.  Each issue
> > should be tagged in all the main/stable release it is in and
> > contains a SHA1 to a patch from master that contains a fix.
> 
> I personally against such close integration with github and creating two
> different places for communication (ML and github), but as Jason said,
> the core team has no plans to manage it and it will be your decision on
> how you will manage it.

I would say anything that makes this job easier and more robust is a
good idea.

If tracking things on github makes sense for the involved parties then
go for it.

IHMO We do not really have the scale to warrent building a huge amount
of custome automatic infrastructure..

Jason

--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Fri, Nov 10, 2017 at 06:36:28PM +0000, Davis, Arlin R wrote:
> > I agree there is a big need for that. Currently reviewing all the patches I haven't
> > read (only 1000 mails to go...) to see if they need to be backported on top on
> > rdma-core 15 for the next SLES.
> > I'd gladly help maintaining this as I'm spending time on it anyway.
> > I'll leave wiser people debate and ready a doc on how this should be done
> > though :)
> >
> > Nicolas
>
> Thanks Nicolas.
>
> Ok, I am not sure what details the rdma-core maintainers are looking for in a document. Let me start the discussion with the following:
>
> Stable Branch Release
>
> Current Maintainer: Nicolas Morey-Chaisemartin <NMoreyChaisemartin-l3A5Bk7waGM@public.gmane.org>
>
> Upstream rdma-core is considered stable after each mainline release. Branched stable releases, off a mainline release, are on as-needed basis and limited to bug fixes. All bug fixes are to be backported from mainline and applied by stable branch maintainer. Branched stable releases will append an additional release number (e.g. 15.1) and will ensure that Travis CI reports a successful build.  Mention the frequency of stable releases or keep it "as is" cadence?
>
> See versioning.md for setting package version on a stable branch.


Nicolas,

I created new branch "stable-v15" in rdma-core repo [1]. Versioning and
releasing should be done by tags, see release document [2]. You should
check in advance that release script [3] creates proper files, and
double check our CI scripts to ensure they don't filter out that stable
branch.

Thanks

[1] https://github.com/linux-rdma/rdma-core/tree/stable-v15
[2] https://github.com/linux-rdma/rdma-core/blob/master/Documentation/release.md
[3] https://github.com/linux-rdma/rdma-core/blob/master/buildlib/github-release

>
> Arlin
>
>
>

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

Re: rdma-core stable releases

[Devesh Sharma]

Hello Everyone,

Can someone guide me how to initiate a pull of my recent submission to
the stable branch. This is quite urgent.

-Regards
Devesh

On Sat, Nov 11, 2017 at 1:27 PM, Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Nov 10, 2017 at 06:36:28PM +0000, Davis, Arlin R wrote:
>> > I agree there is a big need for that. Currently reviewing all the patches I haven't
>> > read (only 1000 mails to go...) to see if they need to be backported on top on
>> > rdma-core 15 for the next SLES.
>> > I'd gladly help maintaining this as I'm spending time on it anyway.
>> > I'll leave wiser people debate and ready a doc on how this should be done
>> > though :)
>> >
>> > Nicolas
>>
>> Thanks Nicolas.
>>
>> Ok, I am not sure what details the rdma-core maintainers are looking for in a document. Let me start the discussion with the following:
>>
>> Stable Branch Release
>>
>> Current Maintainer: Nicolas Morey-Chaisemartin <NMoreyChaisemartin@suse.de>
>>
>> Upstream rdma-core is considered stable after each mainline release. Branched stable releases, off a mainline release, are on as-needed basis and limited to bug fixes. All bug fixes are to be backported from mainline and applied by stable branch maintainer. Branched stable releases will append an additional release number (e.g. 15.1) and will ensure that Travis CI reports a successful build.  Mention the frequency of stable releases or keep it "as is" cadence?
>>
>> See versioning.md for setting package version on a stable branch.
>
>
> Nicolas,
>
> I created new branch "stable-v15" in rdma-core repo [1]. Versioning and
> releasing should be done by tags, see release document [2]. You should
> check in advance that release script [3] creates proper files, and
> double check our CI scripts to ensure they don't filter out that stable
> branch.
>
> Thanks
>
> [1] https://github.com/linux-rdma/rdma-core/tree/stable-v15
> [2] https://github.com/linux-rdma/rdma-core/blob/master/Documentation/release.md
> [3] https://github.com/linux-rdma/rdma-core/blob/master/buildlib/github-release
>
>>
>> Arlin
>>
>>
>>
--
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: rdma-core stable releases

[Leon Romanovsky]

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

On Mon, Nov 13, 2017 at 08:47:38AM +0530, Devesh Sharma wrote:
> Hello Everyone,
>
> Can someone guide me how to initiate a pull of my recent submission to
> the stable branch. This is quite urgent.

Most probably, we will follow kernel rules for stable@.
It means patches should be in master branch, no pull requests and we
will use some tag to inform Nicolas to pick that fix for stable too.

At least, there is a need to write (copy/paste from kernel) initial document
with description of process.

Also, I didn't hear commitment from OFED developers that they use this
stable branch.

Thanks

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

Re: rdma-core stable releases

[Vladimir Sokolovsky]

On 11/13/2017 09:15 AM, Leon Romanovsky wrote:
> On Mon, Nov 13, 2017 at 08:47:38AM +0530, Devesh Sharma wrote:
>> Hello Everyone,
>>
>> Can someone guide me how to initiate a pull of my recent submission to
>> the stable branch. This is quite urgent.
> Most probably, we will follow kernel rules for stable@.
> It means patches should be in master branch, no pull requests and we
> will use some tag to inform Nicolas to pick that fix for stable too.
>
> At least, there is a need to write (copy/paste from kernel) initial document
> with description of process.
>
> Also, I didn't hear commitment from OFED developers that they use this
> stable branch.
>
> Thanks

Leon,
I am going to use "stable-v15"  branch for OFED-4.8-1 release once it 
will include all the relevant fixes.

Regards,
Vladimir
--
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: rdma-core stable releases

[Jason Gunthorpe]

On Mon, Nov 13, 2017 at 05:35:49PM +0200, Vladimir Sokolovsky wrote:
> I am going to use "stable-v15"  branch for OFED-4.8-1 release once it will
> include all the relevant fixes.

Do you have a list of fixes you are already carrying in OFED? That
might help Nicolas

Jason
--
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: rdma-core stable releases

[Davis, Arlin R]

> On Mon, Nov 13, 2017 at 05:35:49PM +0200, Vladimir Sokolovsky wrote:
> > I am going to use "stable-v15"  branch for OFED-4.8-1 release once it
> > will include all the relevant fixes.
> 
> Do you have a list of fixes you are already carrying in OFED? That might help
> Nicolas

Devesh Sharma (2):
	bnxt_re/lib: increment psn in case of 0 length packets
	bnxt_re/lib: fix the memory barrier call during poll-cq

Ram Amrani (1):
	libqedr: fix inline data copy





--
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