i evaluated layouts of debian, slackware and netbsd. our layout is similar to that of slackware, with small tinges of netbsd layout. gluster source base is spread across CVS and FTP.. CVS - contains the 'clustering logic' .. informally this is the python source codes.. this is where the active development of gluster happens. this contains gluster-core, gluster-ext, gluster-apps (all python) see http://hardcodecafe.com/~avati/src/gluster/cvs_co_sample for how things should be in the CVS. (This is hereafter referred as 'gluster-cvs') FTP - contains necessary stuff to make gluster LIVE. this includes kernel,libc,python,busybox,dhcpd,inetd,busybox etc.. see http://hardcodecafe.com/~avati/src/gluster/ for how things should be in the FTP server. (This is hereafter referred as 'gluster-live') [Note: cvs_co_sample/ there will be removed] FTP maintainance: Development noise in the FTP is less. commits/changes are sparse and rare. In general, work in the ftp goes on like this: All work happens in gluster-current direcotry. New versions of packages are added here, installation scripts are improved here. Once we have a stable FTP gluster-current tree, development work here will be very little. Since FTP does not favor parallel development, and since the noise here is anyway less, we can have one person be the 'gluster-live maintainer'. All new packages/ install/build script updates should be streamlined by sending to the maintainer, and NOT upload the changes oursleves. Versioning: The principal behind the FTP tree is "build a live image out of package sources". For this, gluster-cvs itself is just another package like inetd. gluster-cvs versioning CAN be seperate from gluster-live release versioning, but we shall keep them in sync. For eg. inetd version can keep upgrading in the gluster-current, but we dont do a new release of gluster-live for a new version of inetd. similarly gluster-cvs version is independant of gluster-live version, but as a thumb rule, to avoid confusion, we keep them in sync, i.e for every new release of gluster-cvs, we do a release of gluster-live with the same version number. Releasing process: A snapshot of gluter-current is copied into gluster-$VER for $VER release. Inside gluster-$VER, an automation script is run which tarballs the source direcotry into a single tarball. Each 'Arch' maintainer takes the tarball, 'extrand-and-build.sh' with the tarball, and releases the 'dist tarball' and of-the-shelf-usable ISO image inside gluster-$VER/$ARCH. There is NO ISO or DIST for gluter-current. A top level symlink 'gluster-latest' points to the latest release directory for easy of search for downloads. Building completely from source: For Mr.Average, gluster-$VER/$ARCH/gluster-$VER-$ARCH.iso is all what he needs. for Mr.Hacker who wants to compile _everything_ from sources, here is the procedure. wget -r http://../gluster-current/sources cd gluster-current/sources ./extract-and-build.sh gluster-current/sources contains a daily cvs snapshot which will be used in the above step. NOTE: cvs co of gluster-cvs and make/make install will result in 'NATIVE MODE INSTALL'. for a LIVE image, the above step should be followed This is a top-level view of how things work. Finer details of script names, directory structure within source/ $ARCH/ are to be discussed after a feedback for this document. feedback please regards, avati -- Once upon a time there was a DOS user who saw Unix, and saw that it was good. After typing cp on his DOS machine at home, he downloaded GNU's unix tools ported to DOS and installed them. He rm'd, cp'd, and mv'd happily for many days, and upon finding elvis, he vi'd and was happy. After a long day at work (on a Unix box) he came home, started editing a file, and couldn't figure out why he couldn't suspend vi (w/ ctrl-z) to do a compile.
