Introducing core, stable/unstable IMPORTANT asking for FEEDBACK

Duncan Gibson duncan.gibson at xs4all.nl
Sun Mar 18 12:34:49 CET 2012


> For that some definitions, we should discuss on (so the following part
> is my own opinion):
> -moonbase-
>     core:
>         [...]
> -mars-
>     stable:
>         [...]
>     unstable:
>         [...]

After my first reply and v4hn's response, it struck me that we are really
dealing with two different things here, and that might need clarification.

The first is: can we categorize modules into levels of importance?
the second is: how should we apply updates/changes in each level?

I misinterpreted the core/stable/unstable labels as asking the first
question, which I then answered (modules for the ISO in core; LAMP,
the core of X, xfce and kde in stable; and the rest in unstable, with
the possible benefit of automatically generating alpha ISO images).
Maybe we should rename these categories as core / important / other.

Using one git branch for immediate updates to modules ("unstable") and
another for delayed/tested/signed-off updates to modules ("stable") will
allow people to continue to commit bleeding edge modules into "unstable"
and delays early adopter problems propagating into "stable", but does
not really address the first question. We clearly don't want to split
moonbase into separate repos, but does it make more sense to interpose
three top-level sections (core, important, other) into moonbase, or
just maintain a list of modules in each level for which different update
rules may apply, or add a comment in the module DETAILS? Or do we simply
stick to the one-month in the "unstable" branch (or testing and sign-off
by three devs) rule before a module can be updated in "stable" regardless
of whether it is in core, important or other?

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?

Just another 2 eurocents into the Lunar piggy bank.
D.




More information about the Lunar-dev mailing list