Where is the talloc repository?

[Michael Adam]

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.


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

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.

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


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.


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?)... :-)


Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20160315/0ceac339/signature.sig>