[PROPOSAL] Release ldb with Samba on the 6-montly release cycle

[Andrew Bartlett]

On Sat, 2019-04-13 at 16:35 -0400, Simo wrote:
> On Fri, 2019-04-12 at 07:34 +1200, Andrew Bartlett via samba-technical
> wrote:
> > On Thu, 2019-04-11 at 15:27 +0200, Andreas Schneider via samba-
> > technical wrote:
> > > On Thursday, April 11, 2019 10:36:59 AM CEST Andrew Bartlett via
> > > samba-
> > > technical wrote:
> > > > Looping back to the top of this thread to put a reduced proposal.
> > > > 
> > > > I've posted a new merge request here:
> > > > https://gitlab.com/samba-team/samba/merge_requests/374
> > > > 
> > > > The scope is reduced to aligning the ldb version with the main
> > > > Samba
> > > > version, so ldb would share the Samba release cycle.  There is no
> > > > merge
> > > > with the main Samba build, just a change to the version number
> > > > calculations (and so release process). 
> > > > 
> > > > The primary motivation here is to decouple ABI changes (eg adding a
> > > > new
> > > > function) from release points, and so slowing down to a 6-month
> > > > release
> > > > cycle matching the main release cadence of Samba so that new
> > > > features
> > > > have time to bake in master before they are released.
> > > 
> > > Yes, I absolutely agree that SO_VERSION number should be decoupled
> > > from 
> > > release version numbers. This should also be done for the other
> > > libraries.
> > > 
> > > 
> > > If I understand you correctly there will be a libldb release:
> > > 
> > > libldb-4.11 and then libldb-4.12
> > > 
> > > 
> > > Samba 4.11.1 and 4.11.2 will depend on libldb-4.11.
> > 
> > The current WIP patch has the main Samba version string directly used
> > for ldb, therefore allowing ldb to change during a release stream (eg
> > for a security release).
> > 
> > Please look carefully at the MR for the details, I would certainly not
> > wish any more miscommunication!  
> > 
> > > If I understood it correctly than this sounds like a good idea! :-)
> > 
> > Great!  I was sure we could find some common ground.
> > 
> > So from here we just need to know if this (eg) libldb-4.11 needs a
> > distinct tarball to be generated by the release team.  
> > 
> > Now that we are clear on what is being talked about, I have also re-
> > opened this:
> > 
> >  https://gitlab.com/samba-team/samba/merge_requests/371
> > 
> > If we decide not to burden the release team with a distinct tarball,
> > then distributors building ldb would just need to use the main samba
> > tarball and add a 'cd lib/ldb' to their build scripts. 
> > 
> > Finally, this is all just WIP proposals, other variations on this
> > approach are most welcome.  But if you do agree with any of the above
> > please mark that on the relevant MR so I can keep track.
> > 
> > Thank you very much for your thoughtful consideration of the above,
> 
> Creating a separate tarball should be an automatic process that takes
> no manual work, and will make life easier for people that just want to
> build *and* distribute ldb and nothing else.

Are you otherwise OK with the MR?

On the tarball question, is 'cd lib/ldb' in the ldb rpm build scripts
(and a larger tarball size) a particular engineering problem?  I've
tested and the independent ldb build works from the Samba tarball. Can
you spell out your specific concerns here a bit more?

It is just a pile of shell-scripting I would rather avoid tackling in
script/release.sh if I don't really need to.

Given the strength of the push-back I feel like there is something I'm
missing here, because while I had more radical ideas in my initial
writeup I've taken feedback and looked at the minimal practical change
which shouldn't badly break anyone but will make ldb development a
little more smooth. 

I don't propose to remove the ldb build system.  It also wasn't ever
proposed to remove the ABI checks or any of the public libraries.

Is the real concern here that ldb would loose one of the final elements
of it's 'independence' from Samba?  It is sad that the goal, that sub-
elements of samba would encourage new developers to work on contained
subsystems never really worked out.  But ldb has been an incredible
success!  Being the absolute core of the AD DC, with scale and utility
totally unimaginable to all of us involved in the early days, it has
the attention of a much larger team and far more testing then ever seen
before!

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba