directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Fwd: What about Kerberos becoming a separate project ?
Date Sun, 23 Sep 2007 18:21:48 GMT
Oops, as usual, I just click on 'reply' instead of 'reply all' ...

So here is my reply to Alex's mail :

---------- Forwarded message ----------
From: Emmanuel Lecharny <>
Date: Sep 23, 2007 8:20 PM
Subject: Re: What about Kerberos becoming a separate project ?
To: Alex Karasulu <>

On 9/23/07, Alex Karasulu <> wrote:
> Ok let me try to clarify below ...
> On 9/22/07, Emmanuel Lecharny <> wrote:
> > Just to clarify my proposal : I just want Kerberos to be clearly
> > separated from apacheds, as is daemon, shaed and installers.
> Yep I understand that.  But when you create another subproject it's like
> another offering of a product
> that is voted upon etc.  We must be able to support that product in the same
> manner that we support
> the server or studio for example.  Doing so is more than just a matter of
> project organization in this
> sense.   You're telling users that we're open for business and we simply are
> not.  Look at the situation
> we had with the guy who inquired about DNS.  No one could help him.

yeah, makes more sense to me now. I agree with you. Let's finish
Kerberos, let it be a community part before making it a separate
project. It will take time, so I have created a special branch to
evolve in this direction, without engaging the community to move
around code, tests, pom.xml, packaging, etc, before we are ready.

> As djencks said in another thread - I did not review a patch request.  This
> however is different from
> turning back users.  A dev issue can wait but the project really looks bad
> when we tell users sorry
> that functionality we advertise is really unsupported and no one can help
> you with it.  Plus you have
> more users than developers waiting on feedback.

very true.

> > The fact that there is not enough community does not have anything to
> > do with it, being part of apacheds or not won't help at all to gather
> > some new committers around it. However, it can still be a plugin, but
> > I would like it to be less tighly coupled with apacheds.
> >
> > I must admit I don't understand your -1.
> Does it make more sense now?

Yes, much more. Sorry if I didn't get the whole picture, it was not
obvious to me at first sight. My intention was good, but maybe a
little bit premature.

> This veto is with respect to this point in time of course.  This is not for
> ever.  We can do with it what
> we like as long as we have community around the code.

Sure. And I'm working on it.

> Just a heads up on my modus operandi.  I like to take risks sometimes with
> new projects and we did
> that with studio and it was a total success.  It was a risk tho and still to
> some degree is because we
> only have two guys that deal with it.  Generally the rules are that we need
> at least 3 active committers
> to start a subproject.  However going back risks are good to take and
> sometimes they produce good
> results.  Studio is an example of a risk that was very successful.

I think we debated about those kind of risks months ago. TripleSec,
Kerberos, DNS, NTP, etc, are such projects which put us on dire
straigth as soon as some users want to use them, because no more than
one committer is able to help them. We have had to sandbox Naming,
sar-plugin and we are talking about DNS sandbox or moiving it to Mina
for this exact reason. Other subprojects like OSGi are sandboxed just
because we can't work on it before we reach a stable version (namely,

All those decision has to be balanced, and sometime, we win, sometime,
we loose. That's just life, I guess...

> Now I took the risk with the Kerberos stuff and softened the requirements
> because technically it was
> too attractive to forgo.  When Enrique wanted to do cool things with DNS and
> DHCP I was also very
> open but worried since it was moving too fast with a single guy at the helm.
>  So then when we could
> not maintain the quality of support that's when I started battening down the
> hatches.

I agree. Kerberos is really a corner stone we can't neglect. My
proposal was just trying to get it under the sunligts, but I agree I
must finish my homeworks before kerberos being able to become a
standalone project. I must admit I haven't finished what I thought
would take me only a couple of weeks (a gross under evaluation), but
at the end, we should have a code which is owned by the community, ie
not only Enrique or me, but by anyone who can jump into the code,
patch it, improve it, use it. We are far from this point.

> Now I take no risks in this area.  There's just too much exposure here now.
> It's time to hold back
> and fix our issues.

The fact is that ADS as a whole has grown up to a point that it's not
anymore a 3 men proects. David pointed out that may be we are trying
to keep the number of committers low by requesting new committers to
respect a full set of rules we don't even fulfill, but at some point,
I don't think this is what is happening. When I jumped into ADS, it
was Alex, Trustin, Enrique, Alan and a bunch of almost inactive
committers. It was 2,5 years. We are now 11 actives committers : Alex,
Chris, Christine, David, Enrique, Ersin, Martin, Pierre-Arnaud,
Stefan, Stefan and me. The community is vibrant, we have successfully
released 6 versions this year : ADS 1.0.1, 1.0.1, 1.5.0 and 1.5.1, and
Studio 1.0.0 and 1.0.1. More than 6800 people have downloaded Apache
Directory Studio, and around 3000 of them since sept, 1st. This is a
great success, but we are now in a situation where we must be more and
more carefull with the project.

> You Emmanuel are now getting into this code base and this is great.  Perhaps
> Enrique can help
> you and then both of you can help another person who comes on.  But once we
> have 3 people that
> can support this code then we're good to offer it as another product with
> all the exposure that brings.


> I'm in love with the idea that we can offer Kerberos based products
> standalone or as plugins.  But
> we need to do it carefully.

For many reasons I also addressed in my previous comment, I'm 100%
with you on that.

> So keep on increasing the community and let's talk in 12 months. If the
> conditions change so will my
> vote.

Ok, np. It's up to us to make it happen. There is no hurry, we have to
be careful.

Thanks for having clarifying your position, this was good to have the
full picture. I'm backing you now !

Emmanuel L├ęcharny

Emmanuel L├ęcharny

View raw message