Where is the talloc repository?
obnox at samba.org
Tue Mar 15 14:50:47 UTC 2016
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
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.
==> 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
- 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
- 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...
Size: 198 bytes
Desc: not available
More information about the samba-technical