Where is the talloc repository?

[Simo]

On Tue, 2016-03-15 at 15:50 +0100, Michael Adam wrote:
> On 2016-03-15 at 10:45 +0100, Volker Lendecke wrote:
> > 
> > On Tue, Mar 15, 2016 at 10:15:46AM +0100, Michael Adam wrote:
> > 
> > > 
> > > Don't get me wrong: I am more than willing to accept real
> > > arguments, but these don't really seem to click for me,
> > > since they don't my perception of reality and extrapolate
> > > from another case which is somewhat different.
> > If a patch that is supposed to be merged to Samba siting in an
> > external
> > repo for 4 months without any activity is not an argument showing
> > that
> > split repos are a bad idea, I don't know what you would accept as
> > an
> > argument.
> I can only repeat myself. Don't get me wrong:
> 
> I am not actually advocating for or against splitting core libs.
> I am even kind of indifferent. (I can see that it would kind of
> make sense to have the code/history separate from an external
> observer's point of view.  But I understand it creates additional
> strain for the samba process.)
> 
> So I am just trying to weed out the good and viable arguments for
> either side...  Since I fail to see these kinds of relevant
> arguments here in this thread, let me recap from private
> discussions I had with Volker, Metze, Andreas and others.
> 
> tl;dr?
> ==> summary: We've been there, and splitting out seems to create
> more problems that is solves.
> 
> ----------
> 
> Now tl;dr is fine, but sometimes you (at least I) need a few
> words...  Read on for my summary of people's arguments:
> 
> Firstly on an amusing note, I proposed splitting out talloc/tdb
> many years ago myself, I think in 2006/2007, when we were still
> maintaining two copies of those (in samba3 and samba4 repos), and
> at that time I was turned down by Simo (iirc), the argument being
> that this would be too much additional effort for the samba
> development process.  I think this argument still holds.

As long as I recall I have always been in favor of splitting out and
using submodules.

But other team members didn't like the idea of using submodules.

> So here is what I think is the main argument against splitting
> corelibs out:
> 
> - It would put a considerable extra effort on those doing the
>   work in samba/corelib code, e.g.:
> 
>   - Separate code and release process in itself may not
>     require that much extra work (since we are already doing
>     separate release from the subdirs) except for the initial
>     setup.
>   - But keeping in sync for samba development will require
>     a considerable extra effort. We'd need to make sure each
>     change in corelib gets tested with samba and used by samba
>     immediately. This would need more involved autobuild setups.
>     And/or continuous manual surveillance.

The problem here is the "sync" process, this can be automated (tool
that regularly checks the trees are in sync) or eliminated (by using
submodules).

>   - Patches to corelibs mostly get motivated out of samba
>     development. So the level of indirection and additional
>     time could well be a disturbance to the samba development
>     flow affecting possibly many samba developers.

I do not think this really is a problem, they are still core samba libs
with full commit access by team members. The issue is really the idea
of syncing stuff, like any sync protocol, eventually stuff get missed
unless you have a tool to check and reconcile or avoid syncing.

With the right tooling I do not think having to commit to a separate
repo would be a huge issue, it's more or less like committing to a
separate branch.

> On the other hand side, what is the problem with external
> consumers like distro packagers?
> 
> - According to Andreas, it happens that samba ran against
>   unreleased talloc / libfoo code. But with the abi checks
>   in place, how could this actually happen?
>   ==> need a concrete example.

Because samba can build with its own talloc version upstream then you
do not notice if something new has been added at build time, but you
quickly find out in the distro where talloc is packaged and the
"released" library does not behave as the samba code expect it to.
It's not necessarily a C ABI break, could be some internal behavior
samba starts depending on with the same C ABI. The ABI checker can only
check if function signatures or data structures change, but cannot
detect if semantics change, for that we'd need a conformance test
suite.

> - Furthermore Andreas mentioned that it is difficult to really
>   follow the development of the core libs. Well I'd say
>   that it is actually not too complicated. Someone who
>   is a developer and knows how to use git could easily
>   do "git log lib/talloc" in samba and see the history.

It is hard for the casual contributor that only care about talloc or
tdb or ldb, but not the rest of samba.

> So after looking over the above arguments, it seems to me that
> the disadvantages of splitting the corelibs definitely outweigh
> the advantages as it currently stands.

I think the disadvantages are so only because of the rigidity of how
the split is proposed.

> Metze tells me that this all has been discussed on the ML
> some time ago and he had given arguments along the above lines.
> (I'd need to search for the mail.)
> 
> So unless more arguments are brought in, I'd consider this
> settled (again?/for now?)... :-)

The pain remains, we can decide we want to keep things more painful for
some to advantage others, but I would like people to actually be
conscious and be ok with knowing that pain is being caused.

Simo.