Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [VOTE] Retrofitting the old code base with snickers
content-class: urn:content-classes:message
Date: Wed, 23 Jun 2004 11:25:55 +0900
Message-ID: <8093A5616E138848840D8E852F4A8965059217@primary.nanshu.com>
Thread-Topic: [VOTE] Retrofitting the old code base with snickers
Thread-Index: AcRYx5IYgliOU+FTT3iO7SqgHXb/fQAAchdA
From: "?????" <cstaylor@nanshu.com>
To: "Apache Directory Developers List" <directory-dev@incubator.apache.org>

I'm not a voting member, but it sounds like a good idea.

-----Original Message-----
From: Alex Karasulu [mailto:aok123@bellsouth.net]=20
Sent: Wednesday, June 23, 2004 11:13 AM
To: directory-dev@incubator.apache.org
Subject: [VOTE] Retrofitting the old code base with snickers


Hi,

Noel, Jeff and I have had several conversations offline about =
retrofitting the old code base initially imported into the SVN =
repository, with the new snickers LDAP/BER codec.  The goal/intention is =
to have a working hybrid of the new Eve and the older code base early =
rather than waiting for all the features of Eve to arrive in one big =
bang.  This hybrid will be free of any snacc dependencies and hence be =
suitable for release once the project has left the incubator.  It will =
allow those interested to fire up the server and kick the tires.=20

Offline I've begun splicing in the parts of Eve that will allow the =
operation of the old code base using snickers.  I did this just to start =
getting a feel for how difficult it would be.  Soon I noticed that the =
changes were well worth keeping.=20

I could not find a workable point within the SVN repository where I =
could easily salvage the old code base.  Plus I already made really =
drastic changes that well were made fast, and late at night.  There were =
some changes that I made without properly tracking them :-(.  Hunting =
down the changes and merging them with the new ones would have been more =
work than using what I had.  If no one objects, I would like to add this =
code into the subversion repository as a detached branch of the eve =
subproject.  I'm thinking of going this route rather than creating a new =
subproject under directory for a few reasons:
=20
 o this is Eve server code
 o it has been branched but the branch cannot be merged to the trunk  o =
maintenance on it will cease asa the trunk is viable  o the branch will =
be considered a maintenance branch if we=20
   release - no further development will take place outside of=20
   minor bug fixes

The one pitfall with this approach is that there is a history disconnect =
on these files.  They were previously imported with history from the =
sf.net CVS repository into SVN.  So we have all the changes that have =
been made by commiters in the past.  We would be starting the history =
again from scratch at another point in the repository.  Sure this makes =
hunting down changes that happened ages ago a bit more difficult, but =
this is a tradeoff.  I don't intend to support this branch for more than =
a few months.  As soon the server in the trunk can be fired up with the =
backend currently in the sandbox to service requests, I will vote to =
freeze work on the branch.

I know this not the cleanest route but its the fastest immediate route I =
have for a very short term solution.  If a release occurs from this =
branch we will not branch it but just keep it as the maintenance branch =
which we would have had if we forked from the trunk.

So if all approve the idea I'd like to keep rolling to show that Eve can =
come up without snacc4j dependencies; so that we have a server once we =
exit the incubator; and so we can have a little fun too.

VOTE:

[ ] Scratch the whole idea and continue with Eve in trunk
[ ] Create defunct Eve branch using initial pre-subversion code base

Until this vote commenses I will be adding the files to subversion as a =
private branch I can work in.  If the community decides to scratch the =
idea I will remove the checkins immediately.  So please, please, don't =
get offended if you see commits going by - I'm just working on a flaky =
new solaris 10 box and don't want to loose what changes I've already =
made.

Thanks,
Alex