Ok let me try to clarify below ... On 9/22/07, Emmanuel Lecharny <[EMAIL PROTECTED]> 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
