directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: What about Kerberos becoming a separate project ?
Date Sun, 23 Sep 2007 16:05:20 GMT
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.

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.

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?

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.

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.

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

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.

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.

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


View raw message