There's a really loooong juiced discussion going right now on the Tomcat developer list (The subject is: "Re: Review model take 2" )wrt this type of stuff (Veto criteria, sandbox vs. trunk, etc.). I suspect that the results and reasons for the results would apply to all apache projects, so it might something good to draw on as a sort of "Case Study". Just mentioning it as it might be a useful reference point down the line.
Cheers,
- Ole
David Jencks wrote:
I've had some discussions with Alex and Emmanuel and it's become clear
to me that I let a combination of my own frustrations and lack of
knowledge of the history here run away and lead me to making some
unfortunate statements.
IIUC the underlying situation here is that most of the apacheds
community has an informal criterion for code being in trunk and released
-- that more that one person can support the code. This could be from
several people working on it, general familiarity with it, or through
javadoc, documentation, and examples. Through some historical accidents
there is some code in the server that doesn't really meet this criterion
very well and there's some confusion about what to do about it and how
to keep the problem from getting worse.
I believe one step that has been taken is to suggest that new code that
may not immediately be OK be developed in a sandbox or branch until
enough people feel it can be well supported at which time it can be
moved into trunk. I think this is a great idea because it provides a
simple process solution to what was starting to appear to be a personal
clash. ("all defects are process defects") I think it might be a good
idea to have a "production ready sandbox" where working code that needs
documentation or review can sit and gain documentation and comments
until enough people agree that its supportable. It might be advisable
to move some code out of the server to here.
I don't think there's been an overwhelming amount of discussion about
this process on the dev list so I'm hoping that if I'm right about this
process we'll hear more about it and that it will be documented
somewhere on the project web site. And if I jumped to yet more
unjustified conclusions I look forward to hearing about them as well :-)
thanks
david jencks
On Sep 22, 2007, at 11:14 PM, David Jencks wrote:
dunno alex. but this strikes me as a bit strange for you to be
criticizing Enrique for thinking about adding new features whereas for
the last month you were too busy adding new features to review a
pretty simple code cleanup patch.
I'm also a bit unclear exactly what you mean by "I'm just going to say
no for now". To me this looks like a proactive veto of code that
hasn't even been written yet, without a technical justification. I
don't quite see how that fits into normal apache procedures. What am
I missing?
I thought one of the ways to make an open source project flourish was
to encourage people to contribute what they want and can contribute.
I think that telling people their work is not welcome is likely to
keep the contributor base, well, extremely manageable.
Personally I think this is looks like a nice bit, not that i
understand any deep details about it, and if my voice meant anything
i'd encourage Enrique to work on it. If he wants to write more docs
than he already has on some other bits he's contributed that would be
fine with me too, but I usually find that docs are wrong by the time
they are actually written and available. I generally find clear code
is a better bet.
BTW, where are the developer and user guides for the dynamic schem
stuff? I'm probably just not looking in the right place but I haven't
been able to find the docs on how to use this feature.
And finally, what are
http://directory.apache.org/apacheds/1.5/dns-protocol-provider.html
http://directory.apache.org/apacheds/1.5/dns-protocol-configuration.html
which I found in the advanced user guide table of contents?
I hope I'm not burning too many bridges with this email but I can't
say I have any desire to work on a project that features responses
like this to proposals for cool new stuff.
thanks
david jencks
On Sep 23, 2007, at 12:11 AM, Alex Karasulu wrote:
IMO if you have some time you might want to start work on some
developer documentation
on DNS as well as a user's guide so we can attract more committers
while answering user
questions around DNS.
Just this week someone asked about this on the users list and all
they heard were crickets.
Emmanuel had to sit there and tell the guy that we cannot support him
and its an embarrassment
for us. He had to apologize for your actions. That's not cool.
Although I want to see you make strides on adding new features to
Kerberos I think it's a bit irresponsible
for you to get back into new features without documenting others that
you added in the past.
You just can't do that while you leave the DNS situation in a poor
state. Do you understand
the point I'm trying to make here? Do you see some merit in what I
am saying from a community
perspective? I'm trying to get you to understand where we're coming
from and not think this is
at all any means to lessen your value. We really like the technical
things you do but a community
is not just about the code.
It's antithetical to OS culture to just drop code or features into
some project and leave. You have
to take care of the users, the developers that come after you so the
project is alive rather than being
an inanimate piece of code. By suggesting this new feature addition
before taking care of your
inherent responsibilities to the community clearly shows that you're
not thinking about these aspects.
This is why I'm going to just say no for now.
Secondly with respect to technical matters how does this impact what
we have in Triplesec
with HOTP? Is this another SAM type for the kerberos server which
uses the class loading
scheme we already have in place for verifiers?
Alex
On 9/22/07, *Enrique Rodriguez* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi, Directory developers,
I have a window with no major deadlines for the next few weeks, so I
looked into adding 1 new Kerberos feature for the next
release. After
doing some "due diligence," ie reading the relevant specs and
reviewing what support I need from the JDK and various libraries,
I am
highly confident I can add PKINIT support for 1.5.2.
PKINIT is a pre-authentication type for Kerberos (detailed in RFC
4556). For those not familiar, PKINIT can be quickly summarized as
"smartcard authentication for Kerberos, replacing the
username/password." PKINIT can also work with a local keypair, so
there isn't a requirement for hardware like an actual smartcard,
though that is the intended deployment scenario.
Since this is only a new pre-authentication verifier, I would rather
not branch and instead develop this, at first, in my sandbox. I have
time starting this weekend, so I'd like to start to get code
committed, to back the code up.
Enrique
