Introducing core, stable/unstable IMPORTANT asking for FEEDBACK

Duncan Gibson duncan.gibson at xs4all.nl
Sat Mar 17 01:04:08 CET 2012


Here's my feedback (but I won't have much time to contribute)

Good initiative. More comments below.

> 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)

moonbase/core should contain every module needed for an ISO image, and
maybe then we could look at generating an "alpha" ISO automatically on a
regular basis (monthly?) or when key modules are updated (gcc/glibc?).

The alpha ISO would allow devs to populate a barebones VM easily in which
full build testing of key modules in mars/stable could be initiated much
more easily than now.

> -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)

one month seems a long time for a bleeding edge source distro, but then
I suppose you can always download unstable, right? Agree about respecting
or asking MAINTAINER more, but then we also need a way of transferring
MAINTAINER if someone goes AWOL.

mars/stable should have the core X11 stuff, and core DE such as xfce4
and kde. If someone would come forward to maintain the Gn*me stuff...

maybe some other key apps could be in mars/stable (languages and LAMP?)
but we should aim to keep it pretty slim too.

>     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.

apart from any work in progress awaiting transfer to mars/stable, all
games, media players, etc. -- basically all other modules - should be
in unstable. Maybe if we had stats on which of these modules were used
then we could decide whether to promote them into stable.

One question: how to handle those core/stable modules that are constantly
being updated? do we wait for the first update to survive a month before
that specific version can be promoted into stable? what about updates,
bug-fixes and security patches that might appear before the month is up?

just my 2 eurocents
D.



More information about the Lunar-dev mailing list