moving libaddns top-level and "merging" libcli/dns

[Kai Blin]

On 2012-05-25 09:30, Alexander Bokovoy wrote:

> Let me know when you analyse changes in those commits in more detail,
> what particularly affects your code in Samba 4 in these changes apart
> from moving files between subsystems.

It's the moving files between subsystems that I object to. The
dns_hosts_file.c/dns.h code is an awful hack. dns.c/libdns.h isn't.

They were in different subsystems for a reason, and I suspect
dns_hosts_file.c/dns.h only ended up in libcli/dns because nobody
bothered to find a different place for them.

...

> All other changes were to make dependencies between subsystems untangled.

Why does linking the dns server to a hack designed to test other code
"untangle" dependencies?

> 
> Also sorry to be harsh, but claiming the code in Samba 3 being
> 'untested' is a bit of a stretch.

It's not run in make test, so it's untested in the samba development cycle.

>> libaddns was used in source3 only, and I didn't want to touch that until
>> the libcli/dns implementation was more advanced. Don't blame me for the
>> fact that source3 has some DNS code duplicated, part of that has been
>> around for longer than I have been a project member.
> Since we are dealing with a common source tree, there is no virtual
> fences. We are responsible together for all the code.

Hahaha, good one. I get a very different impression from reading this
mailing list. There's a clear "my code" and "your code" going on in the
project. While I agree that we should strive to not do that, the very
plain truth is that we're not there yet. The simple existence of a
MAINTAINERS.txt file proves you wrong.

> 
>> I'm saying that by putting a library in the top level, it's your job to
>> make sure it's clean and doesn't break other stuff that already is in
>> the top level.
> I'm sorry for making your life complicated by moving the code around,
> but is there any specific technical issue?

This isn't a technical issue, it's a design issue. The libaddns library
isn't at all what I'd like to have for a general purpose DNS library in
Samba. Up to you moving it top-level, it was a very s3-centric library
just for allowing s3 to update dns records when participating in an AD
domain. Now it's a general purpose library, and that's what I object to.

> Could you please point exactly what this change broke in behavior
> other than making your rebase harder? Could you please point me to
> specific tests that show the broken behavior? Do we have those tests
> in selftest/autobuild? Can we have them there?

As I said, it's a design issue. I just mentioned the rebase because
that's how I noticed at first this morning when I was trying to get some
actual coding done.

> I'm sorry to hear your claim on code being unrelated. Such claim is
> definitely far from actual state of the functionality and
> implementation that both subsystems bear.

Oh? Can you point me at a line of code that used the libdns client code
and also used the test hacks from dns_hosts_file.c? I'm sure that
neither the DNS server nor the test tools I wrote did.

Kai

-- 
Kai Blin
Worldforge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/