On Tue, Apr 23, 2013 at 4:14 PM, Florian Müllner <[email protected]>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 > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list >
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
