directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [VOTE] Directory project releases II
Date Tue, 04 Jan 2005 04:10:10 GMT
Brett Porter wrote:
>>>>At the moment, I'm not sure that we have a need to release anything
>>>>separately other than naming and the server, and then gain experience 
>>>>those.  These are only technology previews, anyway, until we exit the
>>>>Incubator.  And once we release separate packages, we increase 
>>>>resistance to
>>>>change (as well as expectations).
> I agree with this from Noel.
I hate to say this, since it effectively nullifies my "+1" release vote, 
  but based on comments from Noel, Ken, Roy and Brett, I am beginning to 
think that we should start with a release of "the server" by itself. 
This limits the public APIs that we commit to and allows us to focus the 
project and community on the core asset -- the Apache Directory Server.

We then need to decide -- and get agreement from the incubator pmc -- 
whether or not we are going to develop and release "components."  I 
think the architecture roadmap and plans for integrating naming, seda et 
al into the server are great, but we need to address the core issue 
directly: do we release components from this project, similarly to what 
jakarta commons or db-commons does?

If we do decide to host components, this requires a larger community and 
  more patience -- both internally and externally -- with managing 
dependencies, as others have pointed out on this thread.  Jakarta 
Commons is, IMHO, a great community but one which would not be able to 
function without the relatively large number of contributors and 
committers who look after the components.  Even in that community, we 
regularly find ourselves scrambling to ensure that we have sufficient 
oversight for each of the components. I share Roy's concern that if we 
turn Directory into a component foundry now, we will not have the 
necessary committer / contributor involvlement to, as he put it, "make 
collaborative decisions."

I feel like [naming] is OK from an oversight standpoint at this point, 
but honestly, just barely (thanks to input from Hen, Brett, Noel and 
Alex). I think the core server is also OK, especially if we focus the 
seda / mina / asn1 / janus bits on supporting the server project.  I 
don't think we have the community -- committers or contributors -- to 
sustain components independently at this point. I may be wrong, that is 
just my opinion. This doesn't mean that we can't work on them though and 
we can't modularize -- it just means that we can't "productize" the 
modules. I like the idea of using the architecture roadmap to bring the 
modules together.  At the same time, I agree with Roy that we shouldn't 
rush to "polish the stones" while we "build the wall" (stealing his 

I would be happy to hold off releasing [naming] independently and focus 
on the integration work - and contributions in other areas - if we feel 
that is the best direction for the Directory project.  As I said before, 
I would also be happy moving naming back to Jakarta Commons.  In any 
case, we need to settle the core isssue: do we, at the present time, 
develop and release distinct components from incubator-directory?  I 
used to be +1 for this, but am now -0.

> Perhaps. I think all you are doing is evolving these components at a slower rate
> using your own use cases as a basis. And this project probably has the
> fundamental use cases down pat :)

I am not sure this is the case for [naming], but could be true for the 
others. My experience in j-c and elsewhere, however, makes me leery of 
this kind of assumption.

> I get the feeling that they are designed well enough to evolve to changing
> requirements over time. At what point they get adopted is more about when the
> community can support it.

Exactly - "when the community can support it" - which is when we should 
think about packaging them separately.
> I've learned this the hard way with Maven. Everybody had a piece of it pre-1.0
> (including me when I was an early adopter), and that later put a lot of pressure
> on getting 1.0 out because of all the conflicting pressures, and more time is
> spent thrashing - helping users get over the problems of early adoption - rather
> than coding and documenting something that people can pick up and work with.

Was some of this due to the plugins, which are sort of analogous to our 
components?  Would you have had an easier time if you limited the 
initial set of plugins?

View raw message