Re: libmlx4 and libmlx5 git trees? Who is handling those?

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

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

On 09/28/2015 03:00 PM, Jason Gunthorpe wrote:
> On Mon, Sep 28, 2015 at 06:18:52PM +0000, 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, and it is so easy >to slap a version number on the HEAD if a distro/ofed/etc wants one.
>>
>> This may be true, but since it is the master, there could be all
>> kinds of new stuff in it and not just the simple bug fix a H/W
>> vendor might want to put into his/her user-space H/W specific
>> library. Consider the situation when some H/W vendor just wants to
>> provide a simple fix to their library.  In the current model, they
>> simply fix it and release a new H/W specific library that a customer
>> or distro can pick up and ship.
> 
> It makes very little difference, once a distro has gone stable they
> will review and inspect all patches - checking a new tar release for a
> sub component or backporting a git patch for the same subcomponent are
> very similar end results.
> 
> 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.
> 
> And again, if the master is unusable, then we have not done our job
> right. The master is *NOT* for stuff that doesn't work.
> 
>> 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 that, that violates the spirit
> of how the uabi side is supposed to work.

Actually, that's not true.  Master is for things that have reached a
state where we think they work and are ready to commit to them.  Between
releases, you can add a number of new features.  The on demand paging
feature went into master for libibverbs a while ago.  The checksum
support patches didn't go in until after those.  The on demand paging
feature is pretty invasive, while the checksum patch set is very
minimally invasive.  As a distro, I can take the checksum patches, but
the on demand patches need bake time.  None of that violates the spirit
of the libibverbs development, but it still doesn't necessarily match up
with distro needs.

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 process that helps to make sure we don't see things like what we
saw with librdmacm (sorry to pick on you Sean): 1.0.17/1.0.17.1,
1.0.18/1.0.18.1, and 1.0.19/1.0.19.1.

As for bundling the packages together, I'm fine either way.  I don't
think there is a huge benefit to one method over the other as long as
all the maintainers can coordinate work that needs to be coordinated.
It might be a little clunky to write all the autotools checks to make
sure you don't compile a version against another incompatible version,
but the tradeoff is that you can do separate updates easily to fix bugs
in the dependent packages.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



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