directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: [1.0.0 -> 1.0.1 Migration]
Date Thu, 18 Jan 2007 15:57:35 GMT
I'm partially volunteering for the site stuff,
in the context of some of the stuff I had to say
regarding documentation earlier.

We may have an immidiate need to get information out
there (Allthough I would say that that immidiate need
should be driven by the need to make user support and
collaboration more efficient - so that if we are
seeing that specific items are slowing us down, then
we should push items that we can say "look here"
with).

What I mean by partially volunteering that is that I
will be creating a process and system around
documenting in microformats, so that precanned
templates can be used around defined documentation
tasks, showing how to use it and suggesting that we
use it.

This way we can document in the microformat we prefer,
specify rules for pulling the document into a larger
context, and were done.

My first thought of a larger context is something like
an Eclipse Help System.

It can be used right out of the box standalone.

However I intend to rebuild the Eclipse help so that
it becomes more of a collaboration portal, where users
can work in Eclipse on their desktop, but their
versioned changes in through the portal for
collaboration.

So I'm mentioning this because I personally am way
more effective documenting in a local desktop eclipse
context.  I'm guessing others feel the same way.

My big concern is once something gets onto Confluence,
how is it going to get reused and updated efficiently.

My personal worka around for that is to just use APT,
put the stuff in my little cookbook microformat, and
point people to that document when they have
questions.

This way I now that later on I can pull my microformat
into a nice html transformation, and assemble it into
a larger context.

This way the works looks professional, gets indexed,
and requires minimum maintenance when it comes to
reformatting, restructuring, restyling, etc.

So I'm just floating this so that we are conscious of
it, so that those that are interested can prepare
their materials with this type of approach in mind for
later.

Start with the end in mind and work backwards.

Cheers,
- Ole

--- Alex Karasulu <akarasulu@apache.org> wrote:

> 
> 
> Emmanuel Lecharny wrote:
> > 
> > Hi,
> > 
> > we have had a discussion recently about the path
> we must follow when 
> > migrating from 1.0.0 to 1.0.1 (when this version
> will be released). Some 
> > tricky points have been raised :
> > 
> > 1) Last changes to Attribute(s) have mad
> impossible to reuse the data 
> > stored in a 1.0.0 ADS. This is my fault, and I
> think the best thing 
> > would be to revert to the previous names for those
> classes (it was 
> > LockableAttribute(s)Impl, renamed to
> Attribute(s)Impl). Of course, I 
> > will also get rid of the added field in
> Attributes, which is not really 
> > critical (it was added to be compliant with the
> JNDI interface, to 
> > support case sensitive attributes name, and this
> is obviously a nonsense 
> > in LDAP context). Last, not least, as those data
> are serialized, I must 
> > be sure that the serialVersionUID are the same for
> those serializable 
> > classes. This should do the trick. Did I missed
> anything ?
> 
> No that sounds good E.
> 
> > 2) We have some user who emitted some concern
> regarding their existing 
> > configuration and data. We should insure that both
> server.xml and 
> > log4j.properties are not overwritten by the new
> one. This also include 
> > schemas, and of course, data. I'm pretty confident
> that we could have a 
> > new installer handling such burdens, but what we
> need is a volunteer to 
> > modify it and tro check that it works well...
> Shemas migration could be 
> > trickier... Any volunteer ?
> 
> This will not be easy to do.  Like I said for
> upgrades we should ask 
> people to use LDAP studio where we can replace jars
> only and massage the 
> store.
> 
> > 3) Another idea would be to first export all the
> dataz from the current 
> > 1.0.0 install, and reimport them into the new
> 1.0.1 install. Guess how 
> > long it could take with millions of entries ...
> However, do we have any 
> > user with more than a few thousands entries ?
> 
> Right this is in general a lousy thing to have to
> do.  5 million entry 
> additions takes a few hours (~4).  It will be
> unacceptable in most large 
> directories and companies.
> 
> > 4) At this point, it would be good to know about
> real users, to be sure 
> > that they are not impacted during migration
> process, and that we can 
> > dedicate some time to support them. Even better if
> some of the 
> > courageous ('First Mover Advantage') users can be
> alpha-testers ... wdyt?
> 
> Yes that would be nice.
> 
> > 5) It would be really great if we can coordinate a
> release with a newer 
> > version of the site and of the doco. I must admit
> that Doco has been 
> > really improved since 1.0.0, but the site still
> suX (tm). Any volunteer?
> 
> Yeah this is really critical for us.  Why have we
> not switched yet to 
> using confluence instead of the maven site?
> 
> Alex
> 
> > begin:vcard
> fn:Alex Karasulu
> n:Karasulu;Alex
> org:Apache Software Foundation;Apache Directory
> adr:;;1005 N. Marsh Wind Way;Ponte Vedra
> ;FL;32082;USA
> email;internet:akarasulu@apache.org
> title:Member, V.P.
> tel;work:(904) 791-2766
> tel;fax:(904) 808-4789
> tel;home:(904) 808-4789
> tel;cell:(904) 315-4901
> note;quoted-printable:AIM: alexokarasulu=0D=0A=
> 	MSN: aok123@bellsouth.net=0D=0A=
> 	Yahoo!: alexkarasulu=0D=0A=
> 	IRC: aok=0D=0A=
> 	PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4
> 014A 3662 F96F 4E13 70F8=0D=0A=
> 	
> x-mozilla-html:FALSE
> url:http://people.apache.org/~akarasulu
> version:2.1
> end:vcard
> 
> 



 
____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it now.

Mime
View raw message