Introducing core, stable/unstable IMPORTANT asking for FEEDBACK

[Jean Bruenn]

Hey Duncan,

i have no opinion about the important/etc naming. However, for those
things beeing two different things (core / userbase split + unstable /
stable) i start to think i should have written about them separated,
however. The initial idea of splitting the core from the userbase came
from auke, me and a few other devs liked the idea but we know it needs
a little bit more thinking. That's why we need auke involved in the
core / userbase split - To think more in depth about it. However, this
is a change which _will_ happen and thus i named it already.

The problematic part with this core and userbase part is, that both
needs to be merged for the user into moonbase.tar.gz. Look at it like
this:

	core + moonbase-master = moonbase
	core + moonbase-stable = moonbase

Where as "core" could be stable and unstable as well, but that's not
planned, yet. Ratler said that merging both using git wouldn't be very
difficult (with a submodule in git or something like that) - Anyway, as
you see, we need to think a bit more about it.

The second thing, is the unstable/stable part, which is implemented
now. Now we need willing developers to work on the stable part making
it really stable, fixing things, working through the bugtracker so that
our "stable" moonbase will reach a "stable" state - without any updates
for now. We're just fixing. And this doesn't change things for other
developers, they can still update things as they're doing right now,
because by default they're working on master - which is
unstable/current/latest.

Look at master (moonbase) like release-candidates for 
        stable (moonbase branch' stable)

Once stable is really stable, and if everyone of us is fine with it, we
can switch it from theedge to lunar and people can start to use it. And
we can start to take updates from lunar master into it every now and
then (depending on the rules)

I'm thinking about the process of a module like this:
  module xyz has an update and announced it on the website.
  developer abc wants to have it in lunar - he commits it after testing
    into master. He may not commit it into stable now.
  a month later (or fixed period of time) another developer would like
    to have it in stable (yes we need some mechanism telling us its
    available) - he's checking if a maintainer is set in stable, if yes
    he's contacting him and asking if there is anything against updating
    it - accordingly the dev will update or won't update it. If there is
    no maintainer he has to let the module checked by one or two
    (initially i said two) more devs before it may be committed.
  the module was checked by three devs successfully, it has been
    comitted to stable now - everything alright.

We might make exceptions for security patches or urgent bugfixes. Well.
Thats how I look at it. 

> Jean's patch to add MOONBASE_TYPE to theedge is a good start, but I
> think it would be useful if there was a lunar web page which showed
> the relative ages of the modules in "unstable" against those in
> "stable" so that people could see which were approaching the month
> probation period. Or a local tool option similar to 'lvu expired'
> perhaps that could extract and compare UPDATED for all modules in
> "stable" and "unstable"? Could such a web page or tool display
> modules based on their core/important/other category?

I already wrote Striker an eMail and asked him if he could make a box
on the front page which would show information about the stable branch.
Maybe i can work some bash script with ratler out which will check
regurlarly for modules in unstable, which might possibly go into stable.

Jean