Re: Feature proposal: combined system status menu

[Luc Pionchon <pionchon luc gmail com>]

On 24 April 2013 04:54, Mathieu Bridon <bochecha fedoraproject org> wrote:

On Wed, 2013-04-24 at 04:00 +0300, Luc Pionchon wrote:
> On 24 April 2013 02:14, Florian Müllner <fmuellner gnome org> wrote:
> > On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari
> > <marco scannadinari co uk> wrote:
> >  > I think your suggestion of a "feature" branch can be a worthy
> > compromise, though.
> >
> > Except that Bastien is right - while on a branch, a feature will
> > hardly be tested by anyone than other core developers of the same
> > module. It's unfortunate, but "real" users generally only get to test
> > a new feature once it appears in their distro (read: some time after
> > the feature appears in a stable GNOME release).
> >
> A branch can be packaged as well.
>
> So one module could have two packages.

Who will package them? For which distros? With how much delay?

The same people who packaged the application previews?

> One with "mature" UI changes.
> One with "controversial" edge UI to be tested.

Now consider the many modules forming GNOME. Do you build the "edge"
package of, say, GNOME Shell against the "mature" package of GLib? Or
also against the "edge" of GLib?

glib (or gtk) are very bad examples. They never ship immature features/API. You will never see a package libglib+crap.

On another hand, that's a very good example, because immature glib/gtk content has been shipped either part of other modules (for example libgd), or in a separate module/package (libegg, in the past). Unless there was no option to disable the "immature" features.

Such a solution would quickly lead to an explosion of possible
combinaisons of edge/mature packages.

No... you strongly exaggerate the solution to prove it wrong (this is unfair). If something works at one scale, it does not have to necessarily work at an upper scale. Concretely we speak about one feature preview, maybe some more. There is no concrete perspective for such explosion.

 

Unless you mean that a user must install the "edge" package for all
modules if all they want is to test the "edge" of GNOME Shell?

(idem)

 

If so, how is that different from just installing the 3.9 packages in a
development distro?

3.9 packages are for developers, as I understand it. Things may break.

The main point is that so-called "controversial" features does not have to be either a hard default, either rotting in a branch. They can be shipped as default, but with a way to revert them in the case they block the user.

I thought first to a downgrade-able package.

Another way is to toggle it with a setting.

Yet another way, for gnome-shell, is to make it as an extension.

etc.