You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2007/09/22 14:21:22 UTC
What about Kerberos becoming a separate project ?
Hi guys,
I was wondering if we couldn't move all the kerberos code into a
specific subproject, at teh same level as apacheds, daemon, shared ?
Kerberos is really not deeply tight to the apacheds project, so it
could make sense to have it moved in its own place.
If we do that, then it will raise the configuration question
immediatly : configuration is loaded when the server is started, and
we may have some kind of dependencies between apacheds and a separate
kerberos project (and it's probably why kerberos lie down withing
apacheds project). But I don't think this is impossible to deal with
this point.
wdyt ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: What about Kerberos becoming a separate project ?
Posted by Alex Karasulu <ak...@apache.org>.
Yes I remember this conversation we had a while back and this was a good
idea. Perhaps it
still is. The problem I have is with the proposal to create a new
subproject with deliverables
in it. That means more exposure to users who are going to be needing help
etc.
This is a good thing but I don't want to deal with that until we have at
least one or two more
people behind the Kerberos code base. Perhaps you can help Emmanuel get up
to speed
on the Kerberos code so we can grow more community around it. Then if you
want to move it
to Tsec or even have it as another subproject than that's cool.
On 9/22/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> I've always wanted to see all the non-LDAP/directory code move to
> Triplesec. The name "Apache Directory" would make more sense and it
> would clear things up for people who just want a
> directory/LDAP/embedded JNDI provider. It would also put the Kerberos
> code together with the HOTP code already in Triplesec.
>
> Enrique
>
Re: What about Kerberos becoming a separate project ?
Posted by Enrique Rodriguez <en...@gmail.com>.
I've always wanted to see all the non-LDAP/directory code move to
Triplesec. The name "Apache Directory" would make more sense and it
would clear things up for people who just want a
directory/LDAP/embedded JNDI provider. It would also put the Kerberos
code together with the HOTP code already in Triplesec.
Enrique
Re: What about Kerberos becoming a separate project ?
Posted by Enrique Rodriguez <en...@gmail.com>.
On 10/9/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> I would add something to what Alex just said : we didn't anted to make
> Kerberos a separate Apache project, but a separate sub-project, from
> Maven point of view. This was just about an internal refactoring.
>
> Kerberos and Apache Directory Project are tighly coupled right now,
> and will remain coupled for a while.
They are only coupled from a build point-of-view. The entire
directory store is behind an interface. For example, for tests there
is a HashMap-based store implementation.
Enrique
Re: What about Kerberos becoming a separate project ?
Posted by Enrique Rodriguez <en...@gmail.com>.
On 10/9/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> I would add something to what Alex just said : we didn't anted to make
> Kerberos a separate Apache project, but a separate sub-project, from
> Maven point of view. This was just about an internal refactoring.
>
> Kerberos and Apache Directory Project are tighly coupled right now,
> and will remain coupled for a while.
They are only coupled from a build point-of-view. The entire
directory store is behind an interface. For example, for tests there
is a HashMap-based store implementation.
A separate sub-project could help attract committers. A common
complaint I hear from people is that apacheds sub-sub-projects pull in
the dependencies and build overhead of the whole apacheds server.
Enrique
Re: What about Kerberos becoming a separate project ?
Posted by Leo Li <li...@gmail.com>.
On 10/10/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> I would add something to what Alex just said : we didn't anted to make
> Kerberos a separate Apache project, but a separate sub-project, from
> Maven point of view. This was just about an internal refactoring.
>
> Kerberos and Apache Directory Project are tighly coupled right now,
> and will remain coupled for a while.
So, is it possible to get a workable bundle of kerberos client
related class without other part of Directory? I am now studying the
feasible ways to implement harmony's jgss provider.
>
> Last, not least, I see no way for Harmony to use any of the Apache
> Directory project due to the very restrictive condition you have to
> fulfill to become a contributor of this project (ie, not having read
> any line of SUN java source). We can't guarantee that the ADS
> developpers haven't been tainted by SUN code.
The story is here that Harmony really has some other constraint but
it does not mean contributor cannot read any line of sun's code. Due
to its modulity, if one intends to contribute code in security module,
for example, he/she cannot see that part of sun's code.
Furthermore, we intend to include part of kerberos code of a binary
distribution as an external link and not to put the source code into
harmony's repository. It is acceptable providing that the external
dependency is under APL if I have not missed something.
>
> I would suggest first that you contact Harmony peeps to get a clear
> idea of those constraints, and as stated by Alx, you are welcome to
> participate to our project too !
>
> On 10/10/07, Alex Karasulu <ak...@apache.org> wrote:
> > On 10/9/07, Leo Li <li...@gmail.com> wrote:
> > > Hi, all:
> > > I happend to find this thread. Is it a little outdate? :)
> >
> > No not at all the topic can be discussed at any time :). However rehashing
> > the
> > same topic repeatedly is a real PITA when nothing else has changed.
> >
> > > Harmony project is now implementing a JGSS provider which
> > > contains a lot of work with kerberos. We intend to borrow kerberos
> > > related code from apache Directory and it will be great if kerberos is
> > > a seperate project.
> >
> > How about getting involved with the parts that you're interested in first?
> > It sounds
> > to me like you want the client side functionality and I think we already
> > have some of
> > that in a separate client project. Just jump in and get involved with the
> > community.
> >
> > > And I also acknowledge the concern to maintain a
> > > sub project and I think we can give some help if we can and are
> > > looking forward to its becoming true.
> >
> > That's great! Having a separate subproject should not be the driver though.
> > However
> > if there is ample community around the code base then there's no reason not
> > to consider
> > it again. The point being supportability with a healthy group of people
> > around that code
> > base. Please feel free to just dig in and start contributing.
> >
> > Alex
> >
> >
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
--
Leo Li
China Software Development Lab, IBM
Re: What about Kerberos becoming a separate project ?
Posted by Leo Li <li...@gmail.com>.
On 10/10/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> I would add something to what Alex just said : we didn't anted to make
> Kerberos a separate Apache project, but a separate sub-project, from
> Maven point of view. This was just about an internal refactoring.
>
> Kerberos and Apache Directory Project are tighly coupled right now,
> and will remain coupled for a while.
So, is it possible to get a workable bundle of kerberos client
related class without other part of Directory? I am now studying the
feasible ways to implement harmony's jgss provider.
>
> Last, not least, I see no way for Harmony to use any of the Apache
> Directory project due to the very restrictive condition you have to
> fulfill to become a contributor of this project (ie, not having read
> any line of SUN java source). We can't guarantee that the ADS
> developpers haven't been tainted by SUN code.
The story is here that Harmony really has some other constraint but
it does not mean contributor cannot read any line of sun's code. Due
to its modulity, if one intends to contribute code in security module,
for example, he/she cannot see that part of sun's code.
Furthermore, we intend to include part of kerberos code of a binary
distribution as an external link and not to put the source code into
harmony's repository. It is acceptable providing that the external
dependency is under APL if I have not missed something.
>
> I would suggest first that you contact Harmony peeps to get a clear
> idea of those constraints, and as stated by Alx, you are welcome to
> participate to our project too !
>
> On 10/10/07, Alex Karasulu <ak...@apache.org> wrote:
> > On 10/9/07, Leo Li <li...@gmail.com> wrote:
> > > Hi, all:
> > > I happend to find this thread. Is it a little outdate? :)
> >
> > No not at all the topic can be discussed at any time :). However rehashing
> > the
> > same topic repeatedly is a real PITA when nothing else has changed.
> >
> > > Harmony project is now implementing a JGSS provider which
> > > contains a lot of work with kerberos. We intend to borrow kerberos
> > > related code from apache Directory and it will be great if kerberos is
> > > a seperate project.
> >
> > How about getting involved with the parts that you're interested in first?
> > It sounds
> > to me like you want the client side functionality and I think we already
> > have some of
> > that in a separate client project. Just jump in and get involved with the
> > community.
> >
> > > And I also acknowledge the concern to maintain a
> > > sub project and I think we can give some help if we can and are
> > > looking forward to its becoming true.
> >
> > That's great! Having a separate subproject should not be the driver though.
> > However
> > if there is ample community around the code base then there's no reason not
> > to consider
> > it again. The point being supportability with a healthy group of people
> > around that code
> > base. Please feel free to just dig in and start contributing.
> >
> > Alex
> >
> >
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
--
Leo Li
China Software Development Lab, IBM
Re: What about Kerberos becoming a separate project ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
I would add something to what Alex just said : we didn't anted to make
Kerberos a separate Apache project, but a separate sub-project, from
Maven point of view. This was just about an internal refactoring.
Kerberos and Apache Directory Project are tighly coupled right now,
and will remain coupled for a while.
Last, not least, I see no way for Harmony to use any of the Apache
Directory project due to the very restrictive condition you have to
fulfill to become a contributor of this project (ie, not having read
any line of SUN java source). We can't guarantee that the ADS
developpers haven't been tainted by SUN code.
I would suggest first that you contact Harmony peeps to get a clear
idea of those constraints, and as stated by Alx, you are welcome to
participate to our project too !
On 10/10/07, Alex Karasulu <ak...@apache.org> wrote:
> On 10/9/07, Leo Li <li...@gmail.com> wrote:
> > Hi, all:
> > I happend to find this thread. Is it a little outdate? :)
>
> No not at all the topic can be discussed at any time :). However rehashing
> the
> same topic repeatedly is a real PITA when nothing else has changed.
>
> > Harmony project is now implementing a JGSS provider which
> > contains a lot of work with kerberos. We intend to borrow kerberos
> > related code from apache Directory and it will be great if kerberos is
> > a seperate project.
>
> How about getting involved with the parts that you're interested in first?
> It sounds
> to me like you want the client side functionality and I think we already
> have some of
> that in a separate client project. Just jump in and get involved with the
> community.
>
> > And I also acknowledge the concern to maintain a
> > sub project and I think we can give some help if we can and are
> > looking forward to its becoming true.
>
> That's great! Having a separate subproject should not be the driver though.
> However
> if there is ample community around the code base then there's no reason not
> to consider
> it again. The point being supportability with a healthy group of people
> around that code
> base. Please feel free to just dig in and start contributing.
>
> Alex
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: What about Kerberos becoming a separate project ?
Posted by Alex Karasulu <ak...@apache.org>.
On 10/9/07, Leo Li <li...@gmail.com> wrote:
>
> Hi, all:
> I happend to find this thread. Is it a little outdate? :)
No not at all the topic can be discussed at any time :). However rehashing
the
same topic repeatedly is a real PITA when nothing else has changed.
Harmony project is now implementing a JGSS provider which
> contains a lot of work with kerberos. We intend to borrow kerberos
> related code from apache Directory and it will be great if kerberos is
> a seperate project.
How about getting involved with the parts that you're interested in first?
It sounds
to me like you want the client side functionality and I think we already
have some of
that in a separate client project. Just jump in and get involved with the
community.
And I also acknowledge the concern to maintain a
> sub project and I think we can give some help if we can and are
> looking forward to its becoming true.
That's great! Having a separate subproject should not be the driver though.
However
if there is ample community around the code base then there's no reason not
to consider
it again. The point being supportability with a healthy group of people
around that code
base. Please feel free to just dig in and start contributing.
Alex
Re: What about Kerberos becoming a separate project ?
Posted by Leo Li <li...@gmail.com>.
Hi, all:
I happend to find this thread. Is it a little outdate? :)
Harmony project is now implementing a JGSS provider which
contains a lot of work with kerberos. We intend to borrow kerberos
related code from apache Directory and it will be great if kerberos is
a seperate project. And I also acknowledge the concern to maintain a
sub project and I think we can give some help if we can and are
looking forward to its becoming true.
On 9/24/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> 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 <el...@gmail.com>
> Date: Sep 23, 2007 8:20 PM
> Subject: Re: What about Kerberos becoming a separate project ?
> To: Alex Karasulu <ak...@apache.org>
>
>
> On 9/23/07, Alex Karasulu <ak...@apache.org> wrote:
> > Ok let me try to clarify below ...
> >
> > On 9/22/07, Emmanuel Lecharny <el...@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.
>
> 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,
> 2.0).
>
> 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.
>
> Absolutly.
>
> >
> > 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 !
>
> E.
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
--
Leo Li
China Software Development Lab, IBM
Fwd: What about Kerberos becoming a separate project ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 <el...@gmail.com>
Date: Sep 23, 2007 8:20 PM
Subject: Re: What about Kerberos becoming a separate project ?
To: Alex Karasulu <ak...@apache.org>
On 9/23/07, Alex Karasulu <ak...@apache.org> wrote:
> Ok let me try to clarify below ...
>
> On 9/22/07, Emmanuel Lecharny <el...@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.
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,
2.0).
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.
Absolutly.
>
> 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 !
E.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: What about Kerberos becoming a separate project ?
Posted by Alex Karasulu <ak...@apache.org>.
Ok let me try to clarify below ...
On 9/22/07, Emmanuel Lecharny <el...@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
Re: What about Kerberos becoming a separate project ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Just to clarify my proposal : I just want Kerberos to be clearly
separated from apacheds, as is daemon, shaed and installers.
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.
On 9/22/07, Alex Karasulu <ak...@apache.org> wrote:
> -1
>
> Kerberos does not have enough community around it to warrant the exposure of
> having it a
> separate project. It was at some point separate but I purposely merged it
> back in as
> a plugin of ApacheDS.
>
> On 9/22/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > I was wondering if we couldn't move all the kerberos code into a
> > specific subproject, at teh same level as apacheds, daemon, shared ?
> >
> > Kerberos is really not deeply tight to the apacheds project, so it
> > could make sense to have it moved in its own place.
>
> It will be much more integrated once we remove the JNDI layer. It's fine
> where it is as a
> set of separate modules and as an ApacheDS plugin.
>
> Alex
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: What about Kerberos becoming a separate project ?
Posted by Alex Karasulu <ak...@apache.org>.
-1
Kerberos does not have enough community around it to warrant the exposure of
having it a
separate project. It was at some point separate but I purposely merged it
back in as
a plugin of ApacheDS.
On 9/22/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> I was wondering if we couldn't move all the kerberos code into a
> specific subproject, at teh same level as apacheds, daemon, shared ?
>
> Kerberos is really not deeply tight to the apacheds project, so it
> could make sense to have it moved in its own place.
It will be much more integrated once we remove the JNDI layer. It's fine
where it is as a
set of separate modules and as an ApacheDS plugin.
Alex