Introducing core, stable/unstable IMPORTANT asking for FEEDBACK

[v4hn]

Morning everyone,

On Sat, Mar 17, 2012 at 01:04:08AM +0100, Duncan Gibson wrote:
> > 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.
 
That's a nice idea, however things like XOrg/mesa are not supposed to be
shipped with the ISO, are they? Jean proposes to include them in CORE though.

First I want to point out that splitting moonbase into core/moon and
other/mars is a change independent from creating mb-stable/mb-unstable!

As we have a lot of complains about broken modules right now,
the most urgent change is creating stable/unstable in my opinion
and we should focus on that. This doesn't even require mars btw but just
another git branch in the current moonbase.

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

This guideline for stable is pretty reasonable in my opinion.
However I'd like to keep the option that as long as the maintainer
or 2 other devs agree, a module can be promoted to stable before time.

A real bleeding edge distro _has_ to be broken every now and then.
But as a _lot_ of users start shouting every time this happens
and even drop lunar as there distro of choice,
only bleeding edge doesn't seem to be an option for lunar.

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

I strongly disagree with that! The purpose of stable/unstable is
to have a usable and a current version of _all_ modules.
Therefore everything that's working without problems in unstable
should be moved to stable after a month of testing.

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

That's what MAINTAINERs are for imho. The most current version should always
be in unstable and a maintainer, that is to say someone who knows about the
internals of the module or at least reads their ml, has to decide what to
put into stable.

One more thing: what about official _unstable releases_ as a couple of
projects feature them? Should they be included in unstable?
I suppose they shouldn't, but as those are "unstable" that would be the branch
to put them, wouldn't it?

Anyway, I really look forward to stable/unstable, as this hopefully
helps to increase the number of developers/users again.

so now it's 4 eurocents,


v4hn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20120317/fe02a8d9/attachment.bin>