On Tue, 19 Jun 2007, Trustin Lee wrote:
On 6/19/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>> What if there were a "frequently updated" dnsjava, containing all of the
>> useful community-contributed patches (including dnsjnio), released
>> under a
>> BSD license - would that be a good solution?
>
> Absolutely. That is the best of the best IMHO. WDYT guys?
Sorry but I don't understand the proposed scenario.
I think the problem is that we need a community around a new dns project
because we want to provide fast respose and more evolution than dnsjava
currently offer.
It is true if Brian doesn't have any will to work closely with us.
He's not replying to us so far, so I agree with you. And I don't
think what Alex is suggesting to us is not so far from what we have
been discussing. He didn't say it should be outside of the ASF. ;)
To be honest, I'm not really sure what the intent here is. For the past 5
years or so, there really hasn't been much need for much evolution or fast
response from dnsjava - there haven't been many features that I've wanted
to add, and there haven't been too many external patches.
The dnsjnio patch set is, as far as I know, the only code that should be
part of dnsjava but isn't. That's mostly my fault - I haven't had much
time to work on dnsjava recently, and evaluating and working with a large
patch takes more time than I've had.
What about the "frequently updated dnsjava" you talk about? Who will do
that? In what environment? What community? As it has been proposed to be
BSD then it cannot be hosted by ASF because the Apache Foundation will
only create/maintain ASLv2 projects (and will also need copyrights for
everything maintained).
Indeed, I really would like to know whether Brian has objections to such
an effort, what would be his own preferences about dependencies (or
evolutions) of his code, if he would be interested in collaborating in a
more "community oriented" project, if he would be interested in an
oversight role.
If someone wants to fork dnsjava, I can't stop them. A "community
oriented" project sounds like a good idea, but as I said above, there
really hasn't been much call for new features. In the 8 years or so since
the first dnsjava release, there's only been 1 serious request for commit
access to the repository, which makes me wonder where the community is.
People occasionally pop up and ask for large features (some of which make
sense), but very infrequently contribute any code.
If the decision was made to fork or evolve the code, I wouldn't object,
but I don't know how much of a role I'd be willing to play. I'm not using
dnsjava in any other large projects, so the only real development I do
(other than applying patches) is adding small features needed for
miscellaneous DNS testing and adding new record types. The main reason I
use dnsjava for testing is that I know the API pretty well, and it's easy
for me to write code using it - if the API evolved to the point that
wasn't as familiar with it and my code didn't work, I'd probably continue
to use the old version or use something else (like dnspython - dnsjava and
small programs using it are the only java code I write anymore).
dnsjava is licensed under BSD-license, so we can fork it without prior
permission, though we need to try. (But he's not responding.) And
starting from the ADS DNS protocol provider is also a good idea. I am
not a DNS expert so it's up to the actual contributor of the project.
If Alex is interested, it's a great news, and starting the project
from the incubator might be a better idea to attract more interested
non-committers such as Alex. Even if we have little code base so far,
we could discuss about this project with the incubator PMC and ask if
we can start from existing code that we didn't write (dnsjava) due to
its inactivity.
I can't really comment on this, as I don't know much about the ADS DNS
protocol provider. Again, though, the "inactivity" you're referring to is
mostly the lack of any necessary changes. dnsjava is pretty standards
compliant. Other than a good asynchronous interface, there really isn't
anything that's missing.
Of course, the inactivity could be the lack of frequent releases to pick
up minor bug fixes. I don't do releases more often because releasing
software on sourceforge is a pain (doing anything with the file release
system takes many times longer than it should), but the code in CVS (which
would have been moved to SVN a year ago if sourceforge's SVN conversion
scripts worked) should be pretty stable, if anyone would like to volunteer
to do more releases.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
