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

