Re: Feature proposal: combined system status menu

[Sriram Ramkrishna <sri ramkrishna me>]

On Tue, Apr 23, 2013 at 4:14 PM, Florian Müllner <fmuellner gnome org> 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).

I don't agree here at all.  First all, we should be able to use ostree and create new images based on the next-gen features branch.  You leave the publicizing of the images to community managers.  That is what we are here for.  I will take care of getting the images publicized.  Create a bugzilla tag for the features branch for each component you have so these people can file bugs against it.

Our infrastructure is becoming sophisticated.  Use it and stress it.  We didn't get all this hardware for nothing.  Andrea and I will try to help out here.

 

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

You just need to have a methodology from getting from a feature branch to the stable branch.  The devil is in the details, but it can be done.

 

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

Again treating your user base as your user test bed is going to create some backlash.  They have signed on to doing things the GNOME 3 way,  don't abuse them by rapidly adding new methodologies that they have to get used to after establishing use patterns already.

All of this boils down to one excuse  and that is the lack of resources.  By that I guess you mean you don't have enough people hacking on the core components.  Because we have the hardware and an amazing systems administrator who is willing to go the extra mile.  We can get more people interested in hacking the platform if we lower the bar of entry and by extension get more testers.  We've made some great progress with that with OSTree and buildbot.

Anyways, I'm going off topic.  My two cents on this.

sri

 

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list