bundy

* Modular * Extensible * Friendly *

[Bundy-users] Splitting out libdns++ (was Gathering of people interested in Bundy at RIPE 68)

Shane Kerr shane at time-travellers.org
Wed Apr 30 20:54:23 CEST 2014


Jinmei,

On Wed, 30 Apr 2014 08:20:29 -0700
神明達哉 <jinmei at wide.ad.jp> wrote:

> At Wed, 30 Apr 2014 11:14:01 +0200,
> Tomek Mrugalski <tomasz at isc.org> wrote:
> 
> > >> If the collaborative decision made will be to continue
> > >> developing DHCP in Bundy, there will be tons of patches flying
> > >> back and forth between Kea and Bundy. Having them done in orderly
> > >> manner would require some planning.
> > >
> > > this is a good point. No decisions have been made.
> > I think that regardless of the decision, some patches will be
> > shared. Even if the decision would be to not develop DHCP in Bundy,
> > Kea is using libdns, libutil and many other libs. There will be
> > fixes in those libs done in both repos.
> 
> Regarding libdns++, I think the ideal way is to unify the effort,
> rather than maintaining the each branch of the fork.  libdns++ was
> intended to be as standalone as possible from the beginning, and
> is generally less dependent on other part of BIND 10/Bundy.  Maybe we
> should make it even more so, e.g., allowing it to be buildable
> separately.  And, then, ideally, Kea could use it as a third party
> library just like Boost or log4cplus, and ISC developers could
> directly contribute to the Bundy version of libdns++ as they find bugs
> or need for enhancement.

I kind of like this idea. Making anything standalone that can be
standalone seems like a good idea. :)

Should we go ahead and pull libdns++ out of the Bundy repository and
put it somewhere on its own then? Perhaps still under the bundy-dns
GitHub organization. I realize this would mean some work on both the
libdns++ and rest of Bundy, but my guess is that it would not be *too*
much work...

Cheers,

--
Shane