[Setup-tool-hackers] Where XST is going.

[Chema Celorio <chema ximian com>]

This is a small document i wrote that explains where XST is going and
lays down the short term plan of the project.
[If you don't know what XST is you can check out:
http://primates.ximian.com/~chema/xst/ to get an idea.]

Note: When i use the term "distro" i really mean "Linux distribution or
Unix system"

Where is XST going
------------------ 

Ximian does not currently have plans to continue the full time
development of XST. The project will become from this point a community
project, we (the hackers) as individuals are part of such community and
will continue working on it. We strongly believe in XST and are very
proud of the current work. We continue to believe that users should
learn how to configure their computer loaded with GNOME, rather than
their particular Unix system.

I will be the maintaining XST, reviewing patches and mapping out the
direction of the project. The project will be renamed to "XST System
Tools". From a user perspective, they are just icons on the Gnome
Control Panel, we don't need to tell the user: "Use XST to configure
this or that", but we still need a project name.

The Big Plan
============

    We need to work smarter. Learn from past experience on what we did
right and what we could have done better. In particular:

    a) Release often.
   
        How many times have we heard this? ok now we really release
often. We need a stable branch (x.even) and a unstable branch (x.odd)
where crazy stuff can happen. We can release every week on the unstable
branch if we need to, releases are almost free (4-6 hours of work from
my part on distant releases 2 hours on releases close together). Release
frequency is proportional to the number of contributors working on the
project.
  
    b) Focus on solving very well a small number of the user's problems
rather than kinda solving a lot of them

        We where trying to solve too many problems of the users rather
than being very good at solving a small number of them. "No more new
tools" till the set of tools that we have work very well on at least one
distro (which can be a different distro for each tool). We made the
mistake of growing the number of tools rather than improving the
robustness and quality of all of them.

       A tool that works 90% of the time is not good enough. For the
short term I'd like us to focus we will focus on the easy, low-hanging
fruit tools and make sure the work really well before spending effort on
new tools: time-admin, users-admin, runlevel-admin, boot-admin,
display-admin & font-tool, in this order. And make sure we don't screw
users boxes, for some (unknown) reason users are not happy if the
display tool crashes X and the current work is lost. I'd like to point
out that because of the backup system that we have there have been very
few problems encountered by the developers because of a bug on a tool,
plus you can just backup /etc as a good measure.

    c) Innovate once we are feature complete

        The archiver & location manager are a great feature, but would
have better been done after the tools where working very well. We can
innovate once the set of tools work really well. For now, focus on
functionality that the user expects.

    d) Better public communication

        We need to improve the public communication of the project, we
where not doing a great job at making public the status/direction of the
project because we where very busy all the time building this "big bang"
release. We need somebody to take care of the web page and use more the
mailing lists. This is really no longer an issue since it is now a
community driven project.
    
What has been happening lately
==============================

* Gnome 2.0 port

    A number of people have helped with the (not yet complete) port to
the GNOME 2.0 platform. However we don't need to port all of the tools
to be usable. As stated in the big plan item B, even if we only solve
one configuration need really well, we are useful.
 
* New developers

    New blood has been injected into the project. Alex, Carlos, Alvaro,
Eduardo, etc.

* runlevel-admin

    By Carlos Garnacho http://www.ultimaorbita.com/garnacho/xst/. Looks
good, not yet ported to 2.0 but carlos is working on it. He (obviously)
has free commit access for runlevel backend & frontend.

* Python bindings

    Tambet started working on a set of Python bindings, he is waiting to
catch some breath from Ximian work to finish them and commit them to the
CVS. The 1.4 version of the bindings where working already but they make
little sense for the 1.4 branch since all new development is happening
in HEAD.

* Finally got off my butt and wrote this mail to let people know what is
happening. (Horray!)

What we need to do, where do we go now
======================================

* Focus on quality & reliability

   As stated above, focus on solving a small set of needs realy well.

* No new tools

   Because of the previous item.

* Leverage from distros that do not have config tools

   We need to make our tools work very well on distros/unices that do
not have good set of config tools. Distros like Debian are good partners
and have excelent communities arround them, very small home made local
distros too (and there are a lot of them). Of course nobody is going to
select what distro/unix to use based on wanting to contribute to XST,
but rather contributions to XST are going to depend on the system that
we use, love or hate.

   Debian and XST have a big synergy between them. They don't have a
standard set of graphical tools and could greately benefit from XST; on
the other hand, the Debian community is could help drive the project
forward in an important way. We will switch the focus from Red Hat into
Debian as our reference platform.

* Make them part of GNOME

   We need to convince the GNOME community that XST shall be part of
GNOME. _Even_ if some distros don't want them, they can just not ship
them. We believe that XST is good for GNOME, a user shall learn to
configure his GNOME system in one way, rather than having to learn each
linux distro/unix. This is the hole point of XST, having one way of
configuring your box. This is good for GNOME and probably not good for
some distros (see below).

* Document the XML so that other implementations can coexist.

    We need to make the XML structure as good as we can and document it
so that other implementations can coexists. We could have a
distro/vendor provide their own set of backends or have someone else
(like php) use our backends and only write the frontend code to interact
with the XML. This is the reason that the backend directory can be
fetched from cvs in its own module and can be autogened by itself.
Longterm: work with the Free Standards Group, once we have working code.

* Porting to the 2.0 platform

* Porting to other distros

Porting to other distros, in particular working on Debian. Debian and
XST have a special synergy between them, but the more distros we can
support, the better.

* Port the font tool to configure xft2, the backend should be trivial
since xft2 is an xml config file.

    Our font tool was a hit the rock hard approach to the font
configuration problem we have. xft2 is the right approach. My current
idea is that the font-admin tool should be a front end to configure xft2
and the rest of the apps/systems should be using xft2.

* Regression testing

    We need a regression testing suite for xst. Without it, we are not
going to be able to scale xst development. Getting the regression test
suite started is a full time contribution. I have some ideas on how we
could do a regression test suit so mail me if you are interested in
taking on this issue, a reasonable amount of experience is needed for
the testing suit for the first backend, writing tests for the rest of
the backends after one testing suite works should not be hard if the
first one is done right.

Distros
=======

Why i belive that distros/unix vendors are not backing up XST.

    - They have invested a lot of time and money in their tools
    - They don't want the overhead of having to work with other people
    - The distros are more interested in making their distro better rather than making GNOME better. The configuration tools are a diferientator for them.
    - <Insert your favorite technical argument here>, which is really not the problem. Languaje they use, why XML, why perl, why GNOME specific.
    - Their tools are going to better at a particular configuration aspect compared to xst.
    - It is easier to write a set of tools for one distro where you control everything in the environment.

Reasons that i belive distros/unix vendors are interested in backing up something like xst
    - They are good guys
    - They want to do the right thing
    - They care about what is good for GNOME
    - Eventual user/customer pressure
    - Less work on their hands to worry about both in the development and in the support side.
    - XST code and architecture is very good
    - XST will lower the entry barrier for new users
    - Pressure from other distros shipping XST

regards,
Chema


_______________________________________________
setup-tool-hackers maillist  -  setup-tool-hackers@ximian.com
http://lists.ximian.com/mailman/listinfo/setup-tool-hackers