Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 66.249.82.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=O1/iC1Jsy3c27wPBPa603364zdIWSZMSyMamAvWZ83k6kTKXmi0j6wgQSOoxyRDhXXisIIvakruMD1Qamzj8dlYiBjSeVJhZhL1a0TLGmEvMax8ZRMPcoGk1L6hMrHPF9ZzWgKD2IO9yEtym/wtoddF/QZLWzCccO9cgHv8DYUo=
Message-ID: <d45b08f00709300042m70ded364y88aa75c2b384c9e@mail.gmail.com>
Date: Sun, 30 Sep 2007 09:42:32 +0200
From: "Emmanuel Lecharny" <elecharny@gmail.com>
Reply-To: elecharny@iktek.com
To: "Apache Directory Developers List" <dev@directory.apache.org>,
	erodriguez@apache.org
Subject: Re: [ApacheDS] Mini-roadmap for protocol work
In-Reply-To: <568753d90709291714u2c41b4e1q5001cafd07582fa3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <568753d90709291507i5d3ef8b5sb3523bfb50827509@mail.gmail.com>
	 <d45b08f00709291538o3d932487v39cfacd301f1fb4c@mail.gmail.com>
	 <568753d90709291714u2c41b4e1q5001cafd07582fa3@mail.gmail.com>

Hi Enrique,


On 9/30/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> On 9/29/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> > ...
> > May I suggest that you just do it in a slightly different order ?
>
> Unfortunately you not only changed the order but you introduced
> substantial scope creep.  While all the changes you suggest are valid,
> I have to package them such that I can actually complete them in OCT.

The scope I'm targeting is the Apache Directory project as a whole. I
not only want a working server, but I want it documented, and
supported. The only way to get it supported is by sharing the code
with the community, which means tests, document and support by more
than one committer. The time frame doesn't matter at all, and if we
get it by december, it's fine. Remember that we decide as a community
what is the good time frame for the project, and we currently are
working on a 2.0 roadmap, which has been agreed on.

>
> > for ( project in {DNS, NTP, DHCP, ChangePW, Kerberos} do
>
> I specifically left out NTP and DHCP, mostly due to time limitations,
> though secondarily since they don't have IoHandlerChain's and because
> they seem to be lower priority given the queries we get.  Certainly
> they are valid concerns, though.

They are, because they are part of the project. Otherwise, we will
have to sandbox all those projects at some point, because we can't
afford users to post questions which don't get answers.

>
> >   1) Add some doco on confluence
>
> Everyone of these protocols (except DHCP, IIRC) has docs in the AUG.
> Any thoughts on what else you'd like to see?

A quick look at those pages just show they are by far not completed.
I'm specifically talking about Kerberos.

>
> >   2) Clean the chain
>
> Removing the chains is an orthogonal concern.  By this, I mean I can
> remove all the chains at once, since it is a similar operation,
> independent of protocol behavior.  I can probably remove the SASL one,
> but I left it out since it is more in the midst of "bigbang" changes.

We will handle the SASL chain removal. I still think that it's better
to remove chains one by one, test them, and move to the next one.
'orthogonal' work usually is a source of problem, because as we have
no tests at all, we have no way to check that something has been
missed (and trust me, I have done this mistake more than often, I know
what I'm talking of:)

>
> >   3) Add some tests
> > done
>
> > ...
> > The idea is to clean the simplest protocols first, and to get me into
> > the last loop when starting with Kerberos. I have still a hell loyt of
> > work to do on the kerberos branch, and I really want to do it with
> > you.
>
> OK.  I am shooting for next month.  Something to consider is that if
> you want to better support users, digging into the code may not be the
> most effective use of time.  Most user questions will be at a higher
> level, pertaining to configuration of the provider and how to
> integrate Kerberos with Linux, Windows, and various services.  I'm
> looking forward to the ASN.1 boost, but, to be perfectly honest, its
> not going to be as valuable to users as getting interop scenarios
> working.

Better support does not mean digging the code. It means being able to
understand what is going on, and also fix some bugs. How possibly can
you tell that a user problem is due to a bug in kerberos or a bug in
the server if you don't have a clear vision of what is going on inside
the guts of the kerberos code? And we also have two kinds of users :
what I call normal users and developpers who may be interested at
using our code.

I think you are also missing a very important point : the ASF has a
clear target : create a community around some project. The code is
nothing if nobody can 'support' it. It's not only about users, it's
about new committers. How can we gather new committers if nobody can
support them?

Now, regarding the present code, my effort was exactly aiming this
target : being able to understand what has been put into the kerberos
server, and leverage what we have done into ApacheDS to avoid a
duplication of effort. Using two differnt libs to do the same thing
means that a new committer will have to spend twice as much time to
handle the code. Not exactly a good idea.

>
> > - you can add your mini-roadmap into the main roadmap
> > (http://cwiki.apache.org/confluence/display/DIRxPMGT/2.0+Roadmap), so
> > that everyone will have a clear visibility about your progression
> > (it's a matter of when we will be able to release : as you can see, we
> > are now 11 working on the project, and we must be much more 'serious')
>
> Will do, once I get some sense as to whether it's "approved."

Whatever work done in this project will be approved considering it's
consistent with :
1) "the Apache way" : http://www.apache.org/dev/committers.html#apache-way
The first point is really important : "collaborative software development"
2) The schedule defined by the PMC

> > Btw, if you have to work on a new external project, it would be cool
> > to tell us so we can define a deadline for some of you assigned tasks,
> > to be able to define the 2.0 release content.
>
> I'd like to wrap-up any work up by the end of October.

Well, then, we will have to setup a compatible roadmap for this work.
If it's not compatible with ADS roadmap, we will have to wait. There
are a lot of thing to do in one single month... Let's discuss that on
another thread.


--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com