survey: BIND Community Edition

[Lyle Giese]

On 01/20/13 02:38, Loganaden Velvindron wrote:
>
>
> On Sat, Jan 19, 2013 at 9:27 PM, Paul Vixie <vixie at isc.org 
> <mailto:vixie at isc.org>> wrote:
>
>     Should ISC create a "community edition" of BIND?
>
>     According to the ISC Domain Survey, BIND9 is the most popular DNS
>     implementation by far. To me this says we're doing a lot that's right.
>     I've heard from many BIND Workers over the years that we could do more
>     -- specifically, that we could be more open.
>
>     ISC's "managed open source" model means there are no non-contracted
>     committers. Every patch we receive from an outside contributor is
>     subject to the same QA and Release Engineering process as ISC's own
>     internal work. This has meant delay in many cases before a code
>     contribution from outside ISC was released as part of BIND. We
>     have also
>     rejected some contributions when they did not fit into our roadmap.
>
>     This raises the question: should there be a community edition of
>     BIND? I
>     envision it as being hosted at ISC but having its own "core team" and
>     having both ISC and non-ISC committers. I can imagine this version
>     being
>     available as an installable package on Linux and BSD, and perhaps even
>     becoming the default for some OS distributions. It could be a proving
>     ground for features that eventually landed in the main BIND
>     distribution. Sort of like Fedora is to RHEL.
>
>     My survey questions are:
>
>     1. would you like, or not like, to see a "community edition" of BIND,
>     and why (or why not)?
>     2. would you run or distribute such a thing in preference to "BIND
>     itself", and why (or why not)?
>     3. would you join such an effort, either as a committer or as an
>     organizer, and how would you contribute?
>
>     Feel free to reply to me directly, or to reply-all and include this
>     mailing list. Either way I will summarize the results.
>
>
> That's an excellent idea ! A community edition would have features
> that people would urgently need and can support themselves. I'd like
> to see RRL integrated as soon as possible, and having a community 
> distribution
> would help test intrusive changes like RRL, and benefit ISC in terms 
> of testing
> coverage and offering support contract for organizations who need RRL 
> deployed efficiently
> but don't have in-house expertise or just prefer to rely on ISC as 
> their DNS vendor solution.
>
> //Logan
> C-x-C-c
>
>
>     Paul
>
I for one am opposed to yet another edition of BIND.  To me, this 
software is essential to the Internet.  ISC, IMHO, has proven to be good 
stewards of the software under their wing.

One of the issues with a community driven version is features that are 
not standards based.  ISC has shown the insight to see down the road 
with some of these requests and see where they may lead in a few years.  
Not everyone has that vision.  And with ISC, you have multiple people 
looking at things that way.  Better chance to forsee these problems.

I am in favor of adding these things as patches to the ISC code for your 
use.  This provides the community test bed for these features without 
the need for yet another version to support and keep the official code 
clean.

Some object to patches because they are too hard to implement.  I 
disagree on that point.  If you want to use a feature 'off the beaten' 
path, you need to be able to compile your own version from source 
anyway.  Adding patches to source code is not hard.  Moving from 
pre-built packages to using source code is a much bigger leap, but then 
YOU are in control of the features, not the feature set some anonymous 
package maintainer thinks you need.

This whole discussion, IMHO, is about features that are either 
one-off(needed by a few) or security needs(rrl, quick response needed). 
I think a patch system is better than yet another version/fork.

I am just not in favor of a 'fork' in bind development.

Lyle Giese
LCR Computer Services, Inc.

P.S.  I am NOT dissing package maintainers!  They provide vital things 
for distros.  But to 99% of the end users, they have no knowledge of who 
you are and users have no real input into the feature set or how a 
package is put together.  For most, that is a great working solution.  
We are discussing things outside of the what package maintainers 
provide.  This is an area where we want/need bleeding edge software 
features for various reasons for a small percentage of users, including 
security(prevent amplification attacks-rrl) or performance in large 
environments(real time database backend).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/mailman/private/bind-workers/attachments/20130120/8a265fad/attachment.html>