On 09/28/2015 06:08 PM, Woodruff, Robert J wrote:
> Jason wrote,
>> IMHO - we should be talking about getting to the point where we can
>> deliver the kernel rc and uapi rc together to someplace like UNH
>> and vendor internal labs and >expect them to test that pair.
>> Regularly, ideally on the ke
Jason wrote,
>I was commenting specifically on the idea that we'd ever release a libverbs
>that forced a kernel upgrade. I hope we all agree that is not acceptable.
This means that user-space and kernel space packages can be released on
separate schedules, so there is no need to tie the two toge
On Mon, Sep 28, 2015 at 04:22:50PM -0400, Doug Ledford wrote:
> >> just a bug fix. Further, that new stuff might even require new
> >> kernel code, so it could not just be replaced as a new user-space
> >> package by a distro w/o updating the kernel.
> >
> > We are not going to make a change like
> >The issue is that basically no one tests the releases of the packages.
>
> We assume that the maintainer of the package tests it before they release
> it :)
No one has access to that many pieces of hardware and system configurations.
The "community" can't dump the responsibility for testing
On 09/28/2015 04:40 PM, Woodruff, Robert J wrote:
> Sean wrote,
>> The issue is that basically no one tests the releases of the packages.
>
> We assume that the maintainer of the package tests it before they release it
> :)
Every package maintainer I know of does. But there isn't a single
pac
Sean wrote,
>The issue is that basically no one tests the releases of the packages.
We assume that the maintainer of the package tests it before they release it :)
The OFED testing then tests all the currently released packages as a bundle
with a released kernel version backported to a distro
> Anyway, I had intended, and I've started on, making a change in how
> libibverbs is done anyway. The idea that a new release is just a script
> that throws a version on and we go is naive. I *will* be doing
> pre-release rc tarballs and there will be testing and there will be a
> release proces
On 09/28/2015 03:00 PM, Jason Gunthorpe wrote:
> On Mon, Sep 28, 2015 at 06:18:52PM +, Woodruff, Robert J wrote:
>> On Mon, Sep 28, 2015 at 10:42:08AM -0700, Jason Gunthorpe wrote:
>>> We are well past the point of doing experimental breaking stuff in the core
>>> uapi libraries. If it is in t
On 9/28/2015 12:39 PM, Jason Gunthorpe wrote:
On Mon, Sep 28, 2015 at 05:28:20PM +, Woodruff, Robert J wrote:
On Mon, 28 Sep 2015, Christoph Lameter wrote:
Right. Its really nasty when you are trying to add features that require
libibverbs and libmlx? changes. Plus it may depend on kernel
On Mon, 28 Sep 2015, Jason Gunthorpe wrote:
> I would guess all-together is actually less work for the distro side
> because the whole candidate patch stream for backporting is right
> there, easy to see, not sprinkled across all manner of git trees.
This is true not only for the distro but also
On Mon, Sep 28, 2015 at 06:18:52PM +, Woodruff, Robert J wrote:
> On Mon, Sep 28, 2015 at 10:42:08AM -0700, Jason Gunthorpe wrote:
> >We are well past the point of doing experimental breaking stuff in the core
> >uapi libraries. If it is in the master git it should be shippable by a
> >distro
On Mon, Sep 28, 2015 at 10:42:08AM -0700, Jason Gunthorpe wrote:
>We are well past the point of doing experimental breaking stuff in the core
>uapi libraries. If it is in the master git it should be shippable by a distro,
>and it is so easy >to slap a version number on the HEAD if a distro/ofed/e
On Mon, Sep 28, 2015 at 10:32:08AM -0700, Christoph Hellwig wrote:
>
> Hi Robert,
>
> getting a package out should not be an issue. master should always be
> in releasable state, and cutting a release should be a simple shell
> script doing all the tagging and uploading.
+1
We are well past th
On Mon, Sep 28, 2015 at 05:28:20PM +, Woodruff, Robert J wrote:
> On Mon, 28 Sep 2015, Christoph Lameter wrote:
>
> > Right. Its really nasty when you are trying to add features that require
> > libibverbs and libmlx? changes. Plus it may depend on kernel changes.
>
> On the other hand, comb
Hi Robert,
getting a package out should not be an issue. master should always be
in releasable state, and cutting a release should be a simple shell
script doing all the tagging and uploading.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to ma
On Mon, 28 Sep 2015, Christoph Lameter wrote:
> Right. Its really nasty when you are trying to add features that require
> libibverbs and libmlx? changes. Plus it may depend on kernel changes.
On the other hand, combining everything into one package limits the ability of
the maintainer of the i
On Mon, Sep 28, 2015 at 11:17:24AM -0600, Jason Gunthorpe wrote:
> Should we combine the user side of the kapi 'core' stack (libverbs,
> all open source providers, libumad, libcm) into one source
> package? Many projects have been working in that model lately with
> some success, IMHO.
>
> Many of
On Mon, 28 Sep 2015, Jason Gunthorpe wrote:
> Should we combine the user side of the kapi 'core' stack (libverbs,
> all open source providers, libumad, libcm) into one source
> package? Many projects have been working in that model lately with
> some success, IMHO.
Yes please.
> Right now we eve
On Mon, Sep 28, 2015 at 11:43:47AM -0400, Doug Ledford wrote:
> On 09/28/2015 11:42 AM, Christoph Lameter wrote:
> > Where are these trees and who is maintaining them? I see that there is a
> > libibverbs on kernel.org that is updated by Doug.
> >
> > There are some mlx4/5 trees around but those h
Doug Ledford wrote:
>git://git.openfabrics.org/~yishaih/libmlx4.git
>git://git.openfabrics.org/~eli/libmlx5.git
The OFA maintainers list contains this for the maintainers of these trees.
ibmlx4 (upstream): Yishai Hadas
http://www.openfabrics.org/downloads/mlx4
git://git.openfabrics.org/~yishai
On Mon, 28 Sep 2015, Doug Ledford wrote:
> On 09/28/2015 11:42 AM, Christoph Lameter wrote:
> > Where are these trees and who is maintaining them? I see that there is a
> > libibverbs on kernel.org that is updated by Doug.
> >
> > There are some mlx4/5 trees around but those have no recent commits
On 09/28/2015 11:42 AM, Christoph Lameter wrote:
> Where are these trees and who is maintaining them? I see that there is a
> libibverbs on kernel.org that is updated by Doug.
>
> There are some mlx4/5 trees around but those have no recent commits. There
> is a libmlx4 on kernel.org as well but th
22 matches
Mail list logo
