Introducing core, stable/unstable IMPORTANT asking for FEEDBACK

[Jean Bruenn]

Hello dear developers,

in the past months more and more developers and also a few users asked
for unstable and stable in Lunar Linux. Until now we weren't coming up
with a solution. Today I would like to introduce an ongoing process to
implement stable and unstable in Lunar Linux.

For that some definitions, we should discuss on (so the following part
is my own opinion):
-moonbase-
    core:
        Modules which are _essential_ for a working environment, may it
        be a server- or a desktop environment (for any environment in 
        lunar gcc, glibc, etc are essential, for a desktop environment
        xorg-server and mesa-lib are essential, for example)
        The rules for the core have to be defined. I'm thinking about
        something similar to the rules i wrote down for stable in mars
        (see the following part) - However, there will be some sort of
        punishment like loosing commit access to the core, if a
        developer doesn't follow the rules (for example updating too
        early, making the system unstable due to not enough testing,
        such things - Seriously, the core will contain those parts which
        are the most important in a system - touching anything here is
        _dangerous_ as it might fuck up a system easily - We need to
        handle this repository just like that.)

-mars-
    stable:
        A module which has been in "unstable" repository for _at least_
	1 month, has no critical bugs in their bugtracker (if
	available), has been checked/signed by three (3) lunar devs,
	plus: If the MAINTAINER flag is set - The MAINTAINER has been
	asked (because he might have had reasons against to do the
	update, that will give him a chance to explain that - If you
	can't reach him within 2 weeks, and all other requirenments
	are met - you can bump it without him)

    unstable:
        Unstable is important, because only modules which have been
        in this branch first, may be considered for the stable branch.
        We won't have any rules for unstable - Obviously you shouldn't
        commit known-to-be-broken modules but you can bump modules here
        as soon as they came out.

Obviously mars will contain all modules, which aren't essential for a
working environment. That means for example firefox, gimp, audacious,
such things. An interesting question would be, what xfce4 is. As most
of our developers (as far as I know and inclusive me) are using xfce4
and xfce4 is the official-used-DE in Lunar Linux, it should go into the
core as well 

The three-developers-rule in stable shouldn't be a problem. zbiggy and
florin are updating a lot, I'm available on IRC every day and I'm
reading the maillinglist, so I can verify modules as well (that makes
3 already) and then we have there a few other developers like dveatch,
el_angelo (and all those whom I didn't name) - I heard nestu and
engelsman wanna come back :) Doing the switch from a module from
unstable-to-stable with contacting a MAINTAINER might take up to 1
month and two weeks, so it shouldn't be a too time-intensive task.

Auke created a GIT Repository called Mars for us on doppio. What needs
to be done is, that two branches are created in it, namely stable and
unstable.

The next step in the route will be to rewrite lunar's
getting-the-moonbase parts to merge mars and moonbase, writing a
dialogue for stable/unstable branch of mars - By doing so I would also
go away from wget'ing moonbase.tar.gz and instead would use git
directly (I'm working on these things, though if anyone wants to help,
always welcome! ).

As soon as this merging is working, I hope that we have a definition of
essential (core) modules and we can start to move modules from moonbase
(core) to mars (not-essential-apps).

As soon as that's done, developers can work on the specific
branches/repository. I think it would be useful to write a few helper
scripts for developers (maybe some sort of automatic mail on the dev-ml
maillinglist) which would inform developers about modules in "unstable"
which stayed there for ~ 1 month, so developers know they could start
to test application xyz.

I'm sure the question will occur, where to put the most recent glibc
and the most recent gcc: Let's first try it with mars stable and
unstable. If that works fine we can modify moonbase to have two
branches, namely stable and unstable, as well. Anyway: Personally I'd
prefer to not have a unstable branch of moonbase (CORE) later, because
we (devs) need to support everything in Lunar somehow, and it's easier
if we have a stable core.

Wow, much written. That said, happily awaiting your feedback, opinions,
agreements and of course the disagreements. Let's discuss.

Jean // wdp