directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "?????" <cstay...@nanshu.com>
Subject RE: [VOTE] Retrofitting the old code base with snickers
Date Wed, 23 Jun 2004 02:25:55 GMT
I'm not a voting member, but it sounds like a good idea.

-----Original Message-----
From: Alex Karasulu [mailto:aok123@bellsouth.net] 
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. 

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. 

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:
 
 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 
   release - no further development will take place outside of 
   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



Mime
View raw message