[Incubation] Shaking the tree

[Nicola Ken Barozzi <ni...@apache.org>]

The Directory Project 'tree' is growing nicely, and I see very nice 
development and cross-project interaction going on.

I'm writing this to "shake the tree" and see what fruits fall: what is 
needed to get out of incubation?

The status page on the Incubator site seems to be lagging behind actual 
accomplishments. http://incubator.apache.org/projects/directory.html

If the specific action items in the "Project Setup" phase have actually 
be done, then I tend to think that Incubation is approaching the end, as 
the community seems to work well.

WDOT?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

RE: [Incubation] Shaking the tree

[Alex Karasulu <ao...@bellsouth.net>]

> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Alex Karasulu wrote:
> ...
> >>If the specific action items in the "Project Setup" phase have actually
> >>be done, then I tend to think that Incubation is approaching the end, as
> >>the community seems to work well.
> >>
> >>WDOT?
> >
> > I think we're doing very well and are coming close to a point where we
> can
> > actually graduate.
> ...
> >
> > Originally one of the criteria I put down for exiting the incubator was
> > the need to have a directory server in an alpha or beta state with 2251
> > compliance.
> 
> I'd say, as I said to the Geronimo folks, to not mix graduation with
> releases. Incubation is about the community, releases are about code. If
> the community is working well and there has been not a release yet,
> there is no reason IMO to delay a graduation.

Very good point I wish you shook the tree earlier :-).  Then I think the
only real issue lies with snacc now.

> 
> > Here are some high level line items that need to be taken care of
> > before we exit:
> >
> > 1. Get the site and documentation polished on all subprojects
> 
> If it's regularly updated it's enough.

Good by me.

> > 2. Have a living breathing server (stubbed all over) to play will
> 
> Make this: have it clear how to get the code and play with it. The
> barrier to entry for outside developers to test the stuff should be low.

Understood, I think this can be done easily.

> > 3. Remove dependencies on Snacc - perhaps the biggest licensing issue
> 
> This is important.

Yes I think it's perhaps the core hurdle to overcome.

> > 4. Accurately reflect status on the cwiki
> 
> +1

Will do.

> > Perhaps the most involved are items #2 and #3.
> 
> #3
> 
> > I think these
> > together will take a few more months.
> 
> I hope not, as #3 should be dealt with much sooner.

What we can do is redirect our efforts towards tackling the ASN.1/Snacc
issues specifically.  Perhaps others can give me a hand with Eve matters 
while I focus on getting snacc completely out of the picture. 

> > So I was thinking graduating
> > the incubator some time this summer if these two points are deemed
> > critical?  I do think we could graduate at anytime since we have
> > something to offer already but I want to make sure we're complying
> > with the rules and expectations of the incubator.  Perhaps I'm being
> > overly cautious - I just don't know.
> 
> Focus on the licensing issue.

You got it.

> > Snacc4J Licensing Issue
> > =======================
> >
> > This is the only matter standing out like a sore thumb so let's talk
> > about it a bit.
> >
> > Frankly if it were not for Snacc4J there really are no other licensing
> > issues.  Basicaly IBM retired Snacc4J.  It's not even available for
> > download.  Also the license is so out there, you can barely even call it
> > open source.
> 
> Wait a sec, is the license Apache compatible? If yes, the fact that it
> has been retired does not stop you from using prior versions (although
> it's not something we want to keep doing for long as it ties us to a
> dead project).

I don't think it is compatible at all.  We'll focus on completely getting 
it out of the picture quickly.  We now see a clear path thanks to your
feedback.  

Alex

Re: [Incubation] Shaking the tree

[Nicola Ken Barozzi <ni...@apache.org>]

Alex Karasulu wrote:
...
>>If the specific action items in the "Project Setup" phase have actually
>>be done, then I tend to think that Incubation is approaching the end, as
>>the community seems to work well.
>>
>>WDOT?
> 
> I think we're doing very well and are coming close to a point where we can
> actually graduate.
...
> 
> Originally one of the criteria I put down for exiting the incubator was 
> the need to have a directory server in an alpha or beta state with 2251
> compliance.  

I'd say, as I said to the Geronimo folks, to not mix graduation with
releases. Incubation is about the community, releases are about code. If
the community is working well and there has been not a release yet,
there is no reason IMO to delay a graduation.

> Here are some high level line items that need to be taken care of
> before we exit:
> 
> 1. Get the site and documentation polished on all subprojects

If it's regularly updated it's enough.

> 2. Have a living breathing server (stubbed all over) to play will

Make this: have it clear how to get the code and play with it. The
barrier to entry for outside developers to test the stuff should be low.

> 3. Remove dependencies on Snacc - perhaps the biggest licensing issue 

This is important.

> 4. Accurately reflect status on the cwiki

+1

> Perhaps the most involved are items #2 and #3.  

#3

> I think these 
> together will take a few more months.  

I hope not, as #3 should be dealt with much sooner.

> So I was thinking graduating
> the incubator some time this summer if these two points are deemed
> critical?  I do think we could graduate at anytime since we have
> something to offer already but I want to make sure we're complying 
> with the rules and expectations of the incubator.  Perhaps I'm being
> overly cautious - I just don't know.

Focus on the licensing issue.

> Snacc4J Licensing Issue
> =======================
> 
> This is the only matter standing out like a sore thumb so let's talk 
> about it a bit.
> 
> Frankly if it were not for Snacc4J there really are no other licensing
> issues.  Basicaly IBM retired Snacc4J.  It's not even available for 
> download.  Also the license is so out there, you can barely even call it 
> open source.

Wait a sec, is the license Apache compatible? If yes, the fact that it
has been retired does not stop you from using prior versions (although
it's not something we want to keep doing for long as it ties us to a
dead project).

> If the Snacc4J dependencies do not have to require the
> snacc.jar to be held here at Apache is that acceptable to allow for
> graduation?  Because if this is the case then we can exist the incubator 
> at any time according to incubation policies.  Please correct me if I'm 
> wrong.

Well, if the license permits you to redistribute the jar, you can do
that on SF and make Apache use that. IANAL, but legally it should not be
a problem. The problem is more of opportunity, and personally I do not
feel that such a dependency advises for a graduation.

> To facilitate this we had already designed an LDAP message framework 
> so different BER codecs could be plugged in and out.  A provider based
> architecture similar to JNDI's architecture enables this.  After 
> writing the framework we wrote a provider for the Snacc4J runtime.  That
> provider is the only project that has a Snacc4J build time dependency.
> 
> Technically we can maintain this provider at the LDAPd sf.net site along
> with the snacc.jar within a maven repo.  Will this help ameliorate the 
> licensing issues enough to allow for graduation?  I'm just thinking out
> loud to see what could be done to expedite graduation.  Once Snickers 
> has come up to speed we can swap out providers.
> 
> How's that sound?

I'd prefer if the whole system could compile and run (even if not fully
feature complete) without this dependency. In this way users could still
swap in the snacc.jar if they wanted, but we would not have that hard
dependency.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

RE: [Incubation] Shaking the tree

[Alex Karasulu <ao...@bellsouth.net>]

Hey Nicola,



> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> The Directory Project 'tree' is growing nicely, and I see very nice
> development and cross-project interaction going on.
> 
> I'm writing this to "shake the tree" and see what fruits fall: what is
> needed to get out of incubation?
> 

I like the analogy! 

> The status page on the Incubator site seems to be lagging behind actual
> accomplishments. http://incubator.apache.org/projects/directory.html

First of all let me apologize for not keeping the cwiki up to date.  
I actually made my first adjustments to it a few days ago.  I'll be 
getting back to it soon.

> If the specific action items in the "Project Setup" phase have actually
> be done, then I tend to think that Incubation is approaching the end, as
> the community seems to work well.
> 
> WDOT?

I think we're doing very well and are coming close to a point where we can
actually graduate.  Subprojects have been factored out nicely from the core 
server like LDAP common, and the Snickers (ASN.1 BER codec) subproject.  
Naming to my knowledge is pretty mature but I think Phil would know better 
than I.  And Janus is taking off with Vince Tence at the helm.  The site as
you know is up and getting filled in as we go along.

Eve also is progressing very nicely.  Soon we will have the new 
redesigned server (albeit with most of the functionality stubbed 
out) ready to come up for the brave and the curious.  There is still
much work to be done before it will be RFC 2251 compliant but I think
our progress will snowball as some of these new features are injected 
into Eve.  

Originally one of the criteria I put down for exiting the incubator was 
the need to have a directory server in an alpha or beta state with 2251
compliance.  Several folks have come forth, both ASF members and
directory project members recommending that this not necessarily be 
the case and I agree.  Some of the other projects are ready and in a 
healthy releasable state.  There is no need to hold them back because
of Eve.  So I think we can forego the need to have a fully compliant 
server.  Let's fallback on just having a server that comes up
and can talk LDAP over the wire.  We'll worry about the details of 
meeting 2251 requirement later once we're out of incubation. 

Here are some high level line items that need to be taken care of
before we exit:

1. Get the site and documentation polished on all subprojects
2. Have a living breathing server (stubbed all over) to play will
3. Remove dependencies on Snacc - perhaps the biggest licensing issue 
4. Accurately reflect status on the cwiki

Perhaps the most involved are items #2 and #3.  I think these 
together will take a few more months.  So I was thinking graduating
the incubator some time this summer if these two points are deemed
critical?  I do think we could graduate at anytime since we have
something to offer already but I want to make sure we're complying 
with the rules and expectations of the incubator.  Perhaps I'm being
overly cautious - I just don't know.


Snacc4J Licensing Issue
=======================

This is the only matter standing out like a sore thumb so let's talk 
about it a bit.

Frankly if it were not for Snacc4J there really are no other licensing
issues.  Basicaly IBM retired Snacc4J.  It's not even available for 
download.  Also the license is so out there, you can barely even call it 
open source.  If the Snacc4J dependencies do not have to require the
snacc.jar to be held here at Apache is that acceptable to allow for
graduation?  Because if this is the case then we can exist the incubator 
at any time according to incubation policies.  Please correct me if I'm 
wrong.

To facilitate this we had already designed an LDAP message framework 
so different BER codecs could be plugged in and out.  A provider based
architecture similar to JNDI's architecture enables this.  After 
writing the framework we wrote a provider for the Snacc4J runtime.  That
provider is the only project that has a Snacc4J build time dependency.

Technically we can maintain this provider at the LDAPd sf.net site along
with the snacc.jar within a maven repo.  Will this help ameliorate the 
licensing issues enough to allow for graduation?  I'm just thinking out
loud to see what could be done to expedite graduation.  Once Snickers 
has come up to speed we can swap out providers.

How's that sound?

Alex