Ok let me try to clarify below ...

On 9/22/07, Emmanuel Lecharny <elecharny@gmail.com> 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 hatches. 

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
vote.

Alex