Re: Feature proposal: combined system status menu



On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari
<marco scannadinari co uk> wrote:
In fact, I think that these sorts of subtle
design-based decisions should be held in something like loomio (see
recent loomio post in desktop-devel), to be later implemented if the
response is positive.

And as has been mentioned on that thread, this is "design by
committee", which is not how it works (or should work). Yes, sometimes
controversial changes are reversed at a later point, and a user vote
would almost certainly have prevented the controversial change in the
first place, but it would also prevent those controversial changes
that turned out right - in particular, neither GNOME 2 nor GNOME 3
would have happened in the first place.


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

So a branch would either
 - be a polite way of rejecting a feature outright - as it doesn't get
any user testing, it is never
   considered ready and punted from release to release
 - land late in the cycle when the few "users" (read: gnome-shell
hackers) that have tested it
   consider it good enough to let loose on unsuspecting users

At least until we get a better testing infrastructure in place, the
only way to get at least *some* user testing is including it in a
development release as early as possible (but only after being
relatively sure that it won't kill any kittens) to get some minimal
exposure to adventurous users of unstable/experimental distributions
(and fellow gnomies running jhbuild sessions of course). It's far from
ideal, but in contrast to artificially holding back the feature, we'd
get at least some feedback (and a fair chance to address issues before
it hits a stable release).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]