PROPOSAL FOR INTEGRATED AND AUTOMATED VECTOR LINUX BUILD =========================================== AIMS ------------------- 1. Users can easily locates VL ISO and packages 2. Developers have an easy to maintenance source 3. Short release period between Slackware -> VL -> SOHO STRATEGY ------------------- 1. Well structured release directory on the FTP site - various VL flavours (base, SOHO) of the same version are under the same tree - the iso of each package is different, but the packages are compatible. - packages are grouped according to the usage - packages has dependency hints 2. Well integrated build directory with automatic script - standard way to make a base system from Slackware - build tree contains the original source tarballs and its compilation settings. - script to compile the tarballs and install them to the base - script to release the packages - script to make the ISO - build tree can be used by farious flavours, only the scripts will be different INTEGRATED RELEASE DIRECTORY ---------------------------- The VL FTP site should be cleanup with this structure vectorlinux : top level veclinux-4.0 : release directory veclinux-4.3 : release directory veclinux-5.0 : release directory dev : top level directory for development veclinux-4.0 : build directory veclinux-5.0 : build directory veclinux-6.0 : build directory for next release VL-On-Crack : anything for testing goes here Each release directory contains iso of any flavours, then common packages + documentation. veclinux-5.0 : version directory, contains all flavours iso : iso for base, contains rc1, rc2, release iso-soho : iso for SOHO, contains rc1, rc2, release packages : official packages that work on any flavours extra : contributed packages doc : documentations with html, images, css, etc. The package directory is arranged according to the LIBRARY, then the USAGE as the following: packages : the package directory con : console based programs (text mode) base : absolutelly required libraries core : essential and customisation packages dev : development edit : editors edu : education, engineering, science ent : entertainment, games, toys net : networking programs gr : graphics mm : multimedia ofc : offices set : settings sys : system & services util : utilities gtk : gtk based programs gnome : gnome based programs qt : qt based programs (do not need kde) kde : kde based programs sdl : SDL based games java : Java based programs x11 : xlib based programs (including xaw3d, motif) The gtk, gnome, qt, ...,x11 contain the same child dirs as the con. Some other small toolkits (lesstiff, fltk) go under x11. Meanwhile gtk extensions like gtkmm, or vxd stay under gtk. I'm considering to put python based apps as a separete tree too since python is huge by its own. Moreover, python based apps are notorious to be compiled (from developer perspective). See that by the USAGE arrangement, user can quickly find the package. For example, to find the firefox go to net directory. Want to know what packages are available for multimedia ? Go to directory net and browse the packages there. By the LIBRARY arrangement, user can easily know the dependency. The chains are : con -> x11 -> gtk -> gnome con -> x11 -> qt -> kde con -> x11 -> sdl For example, if somebody wants to install a GTK based programs, just make sure all packages in these directories have been installed: con/BASE, x11/BASE, gtk/BASE. GTK based programs do not need anything below qt,kde,sdl or gnome. p.s: The dependency will be more clear if the structure is like this, but the tree would be too depth. con x11 gtk gnome qt kde sdl (** NOTE: This was the original plan. After considering the things, the TREE structure is chosen, not the FLAT. The con is changed to cli since "con" is a reserved file on MSDOS. **) INTEGRATED AND AUTOMATIC BUILD SYSTEM -------------------------------------- This is intended for developers, but I'm not going too technical. Please don't be bored so soon ;-) IMHO, to make the VL release integrated and quick, we have to : 1. Stick with a standard release cycle that comprises VL BASE and SOHO as concurent projects. 2. Make automation script, so moving from RC1->RC2->FINAL is a matter of put the fixes in the right places, run the script, get the updated version. Not by hand for every release ! Lets talk about the release cycle first. The common release cycle of Vector Linux is: 1. Slackware comes out. 2. VL RC1 comes out, intended for developers and testers only. It contains the basic software from slackware, updated kernel, updated libraries, and vector linux specific (vlautosetup, vasm, vlinit, etc). This rc1 can be used by developers to build new packages and make customisation. Consequently, we have to make sure that the contributed packages can be used in the next rc. Thus, there should be NO UPDATE for the gcc and the libraries ! The packages that belongs to this category should be put into the BASE packages. For example, X11 packages, gtk, kde-libs, gnome-libs. The developers may add a new BASE package, but never update the existing ones unless a serios flawn has been reported. Developers may do anything good for other packages (core, dev, etc). So lets say that RC1 is the last chance to put the libraries in place. Therefore, the lead developer play an important role of providing the good innitial libraries. Personally, I believe that Patrick has taken care about stability of the libraries. So, it is better and quicker to keep all /l packages from the Slackware intact. This policy also keeps along the slack compatibility, 3. VL RC2 comes out, ready for public testers. This contains the fixes, new packages and customisation from developers, This rc2 should have the final, complete features, look and feel. No major updates anymore after rc2, except bug fixes. 4. VL base final release version comes out. Congratulations, and expect reviews. Traditionally, SOHO development starts after VL BASE. However, our previous SOHO 4.0 development was a failure. The development started too late and lasted too long. Let's learn from the experience. - VL 4.0 was ready, but moving to the initial release of SOHO was difficult since we had to collect many packages from RAW again. There was no trace of previous SOHO. Contributions came a lot, but was build on VL4.0. Meanwhile, a lot of things was changed for the never released SOHO RC0. The contributions were USELESS ! - Then tigger came back. He knew what is needed, so me were moving fast for dev release. - Using that dev release, contributions came like storm. SOHO RC1 came out as the the best looking VL ! - However, for RC1 many upgrades was taken including the KDE libs, even the GTK. They are BASE systems, so ... many contributions for RC1 were going to the JUNK for the second time. We had to rework all over again. - SOHO RC2 suspended until now. The lead developer got busy and nobody can take over, while the contributers must be a bit frustated. That experience should taught us the importance of 1. FROZE THE GCC AND THE LIBRARIES STABLE ASAP. 2. HAVE A BUILD TREE SO VL AND SOHO CAN BE INTEGRATED, ANYBODY CAN TAKE OVER THE DEVELOPMENT, AND THE LEGACY CARRIES ON FOR THE NEXT VERSION. We don't want the developers to keep chasing the moving target, then after giving their best shot, only find their work wasted. So I really really hope, VL BASE RC1 can achieve that frozen state, or at least the VL BASE RC2. Given that condition, the development of SOHO can be started as soon as VL BASE RC1 comes out. Thus, both are concurent projects. 1. SOHO RC1 comes out based on VL BASE RC1/RC2, plus additional BASE libraries including qt and KDE. Use KDE from Slackware if you want to be quick, but upgrading is appreciate. The importat thing is, this is the LAST CHANCE to do so. SOHO lead developer have many things to do. But, since we are working with the already published VL BASE RC1, expect many contributions. 2. SOHO RC2 comes out with good loking contributions. 3. SOHO FINAL comes out with bug fixes. Generally, the release cycle is concurrent like this ASCII diagram: SLACK ---> VLrc1 -+-> VLrc2 ---+-> VLfinal--+ | | | +------------+-> SOHOrc1 -+-> SOHOrc2 --> SOHOfinal Does VL have the man power to do this ? I think so. * VL main developer (vec) get the VLrc1 ready * VL contributors (mutiny, kocil, ..) can start building packages for VLrc2. * SOHO contributors (inggy, maf, verb, ...) can start building specific packages for SOHO (in fact, this can be seen as extra packages for VL). * VL lead developer release VLrc2 * SOHO main developer (tigger) gets the VLrc2 and SOHO contribution to make SOHOrc1. * A bit more fixes and VLfinal released. * Adding customisation from our artists (PastorED, UKBill, ...) SOHOrc2 comes out fully dressed. * Little fixes and SOHO final comes out. See that by frozing the library sooner, our contributors can start building the packages as early as possible. SOHO innitial relase greatly helped by that. Meanwhile, updates and fixes for VLrc2 goes to SOHOrc1 too, while fixes for VLfinal are used since SOHOrc2. So, our testers have less to do. Let's hope that our documentors can catch up :) Frozing the library however, make us a bit outdated. To decrease that, the only way is to speedup the release cycle. We need an automation. This is the dream: 1. Get the Slackware CDROM 2. Install it as a BUILD HOST 3. Upgrade the kernel if needed 4. Install the automation script. Then, use Slackware as development host, we build VL RC1. 1. Prepare additional packages and customization 2. Make build script for VL BASE 3. Run a script to install the new VL BASE from Slackware CD 4. Run a script to add the additional packages 5. Run script to build the ISO 6. Ta da ... we get VL BASE rc1 With some hardwork, it can be accomplished in 4 weeks. Then after some reports come in to the bugtracker... 1. Add more packages from vectelopers (that build it using the rc1) 2. Apply the fix to the source tarball or customisation 3. Run script to install the new VL BASE from VL BASE rc.1 4. Run script to add the fixes 5. Run script to build the ISO 6. Ta da ... we get VL BASE rc2. One more same cycle and we get the VL BASE RELEASE ! Hopefully, within 2-3 months after the Slackware was released. The development of SOHO RC1 is done on the same build tree of VLrc2 (or the copy, because the lead developer is difference). 1. Add more packages and customisation for SOHO 2. Make build script for SOHO 2. Run script to install the new VL SOHO from VL BASE release 3. Run script to add the packages and customisations 4. Run script to build the ISO 5. Ta da ... we get VL SOHO rc1 and the story goes. Can we achieve that automation ? Yes, but the details will be too technical. A simple demo is more interesting. Assume you are going to make VL 50rc1 from Slackware 10. Here is the automation packages and the HOWTO-NEWBIE. ACTIONS ------- If this proposal is accepted, the following actions should be taken. 1. Going public with the plan 2. Assign somebody to clean up and restructure the FTP site 3. Make and test the automation script. 4. Group the developers for VL or SOHO. 5. Use the automation for the the next VL + SOHO release. Looking forward for your comments and suggestions