Collaborative management

KISS and comply to standards

Keep it simple: follow the best standards, carefully draft and write
high quality documentation, provide a stable and robust system and keep
the rootfs on the LiveCD light enough to run on machines with at
least 128 MB RAM. It's also possible to use GTK+2, Dialog, SHell scripts,
or PHP coding tools on the distribution. The idea is not to duplicate and
to think small...

Tank - Build host & home

Each contributor may have an account on the project server with secure
access, disk space, a public directory and all development tools.
Developers can compile packages and maintainers of the mirror can handle
synchronization. Tank also hosts the Build Bot, Web boot and SliTaz Pro:
tank.slitaz.org

Mercurial repositories

SliTaz Mercurial or Hg repos can be browsed or cloned by anyone using
the URL: http://hg.slitaz.org/. People
with write access can directly use repos.slitaz.org which
requires authentication. Mercurial uses Python and is installable with:
tazpkg get-install mercurial

~/.hgrc

Before you push your first commit onto the server, be sure that you have a
correct Hg configuration file with your name and email address, and remember
to check that you are not root. Personal ~/.hgrc file example:

[ui]
username = FirstName LastName <you@example.org>

Clone, modify, commit and push

Clone a repo, example for wok:

$ hg clone http://repos.slitaz.org/wok

Change directory to wok, note you must be in the repository to be able
to use 'hg' commands. To check all logs or just the last log:

$ hg log
$ hg head

Add or modify one or more files and commit:

$ hg add
$ hg status
$ hg commit -m "Log message..."
$ hg log

Note that you can use the command rollback to roll back to the last
transaction. Before pushing changes to the server, it is safe to pull once:

$ hg pull
$ hg push

Done, your changes, code or corrections are now on the server.

Updating a local wok

To update your wok with the local server (pull to pull the changes):

$ hg pull -u

Useful commands

Hg commands that can be used.

hg help : Display the full list of commands.

hg rollback : Undo the last action performed (commit,
pull, push).

hg log <package> : Display a package log.

hg head : Display the last log.

GUI - Pure C/GTK, Yad, Vala/Genie and CGI/web

There are many ways to create user interfaces in the open source world. From
the start of the project until 3.0 we mainly used a tool called Gtkdialog
which let us create quite nice and complex interfaces in GTK, but using a
scripting language that just ran without having to be compiled. But gtkdialog is
unmaintained and lacks many new GTK features, so we switched to Yad for simple GUI boxes.
For all the administration, packages and configuration tools we switched to TazPanel,
a CGI/web interface with a gui coded in xHTML 5 and CSS 3.

Yad is very simple but doesn't allow us to create complex interfaces even if we
only need 2 or 3 entries with labels and a few buttons, so another way
must be found. The advantage of a scripting language is the fact that it doesn't need
to be compiled and can be coded in realtime (but it produces slower applications).
Writing tools in C is complex and gets less contributions since SHell scripts are easier
to understand, so the guidelines are now to keep and continue to improve our
cmdline tools and provide frontends in GTK or CGI/web.

There are many new languages that use GTK such as Genie, Vala or GTKaml.
But keep in mind that they are not as popular as C and GTK and not really
easier to learn and use (for simple frontends you can use SHell
scripts to perform tasks). You can use Vala but look at a pure
GTK single window, it uses only 14 lines:

If you are not sure about which language to use, discuss it on the mailing list.
If you just want a small GUI function, look at tazbox in the slitaz-tools
repo, it has tiny desktop tools such as a logout box. The first
SliTaz sub-project written in pure GTK is TazWeb and you can use it to learn
ways to use system() to include system commands in your frontend. For
example TazWeb uses wget for downloads and sed to add bookmarks.

Implementation of iconv()

SliTaz uses iconv() provided by GNU glibc - any packages that offer
libiconv must use the library contained in glibc-locale.
There is therefore no longer a libiconv package (1.2 MB) in SliTaz.

Building SliTaz packages

Officially building is done with the Cookutils suite. This package is installed
on each SliTaz system as well as documentation about using cook and
creating SliTaz packages
suitable for the TazPKG packages manager.

The tazpkg packages in SliTaz are automatically created via the
Cooker from the Cookutils package
and a receipt in the wok. The Cookbook describes the format of
receipts.
Cookutils and receipt documentation are required reading before we begin.

In terms of choice of package, the idea is to offer a package by task or
functionality, ie. the lightest application in the field and not duplicated.
Note that the current packages are not immutable, if you find an alternative
that is lighter, with more features or more sexy for a few extra KB,
you can suggest it on the Mailing List. Particular attention is given to
packages for the LiveCD, these should be stripped, removing unnecessary
dependencies and compiler options. In general candidate packages for the core
LiveCD are discussed on the Mailing List.

Before you begin to compile and create packages for SliTaz, be sure that the
work doesn't already exist in the
undigest
wok provided by the primary SliTaz mirror. Don't forget that the members
of the list are there to help you and that the
Cookutils
documentation exists to help you get started.

Naming of packages

In most cases the package name is the same as the source, except for
Python, Perl, PHP, Ruby and Lua modules. For example, the package
providing a Kid template system written in Python and XML is named:
python-kid.

Website Management

The website is managed via a mercurial repository, this can be cloned by:

$ hg clone http://hg.slitaz.org/website
Or if you have the proper permissions:
$ hg clone http://repos.slitaz.org/website

xHTML coding style

The pages and different books are coded in xHTML 1.0
transitional. The title of level 1 is used only once (at the top),
level 2 is the title of the document and levels 3 and 4 are then used for
the subtitles. If a list is used instead using smart anchors;
then that starts at the top, just after the title of level 2.
Paragraphs are contained in the tags <p></p>.
For indentation, we use tabs - the reason being semantics and to take
up less space in terms of octets (bytes). To put code, like the name of
a command inside a paragraph: <code> is the preferred
method. To view commands or to utilize a terminal, the web pages use
<pre> to display the formatted text. Example:

$ command

To view text that can be copied and pasted, such as scripts,
bits of code, sample configuration files, etc - we also use
<pre>, but with a CSS class named "script". Example:

<pre class="script">
code...
</pre>

The emphasized words put themselves in the tag <em>
and internal links are relative. Remember to check the validity
of the code via the online validator of the W3C.

Diff and patch

The utilities diff and patch are command-line tools
for creating and implementing a file containing differences between two files.
This technique is often used for collaboration and the changes made to the
original file can be clearly extracted. To create a diff file
readable by humans in a simple text editor, you must supply the -u option: