Re: Design by Community

[Rodrigo Moya <rodrigo gnome-db org>]

On Wed, 2006-02-08 at 19:51 +0800, James Henstridge wrote:
> >>Isn't what we got here exactly what has been asked for? That 'big'
> >>changes to GNOME needs to come from 'outside' projects? Havoc for
> >>instance was advocating that in his blog entries. So if people are
> >>unhappy about XYZ in GNOME, for instance the current panel. Due to it
> >>being so business critical we can't have experimentation going on in the
> >>gnome-panel CVS head, so 'radical' changes would need to be done as a
> >>separate project, and if it turns out good then it will at some point
> >>replace the current module.
> >>
> >>    
> >>
> >this is exactly what I was going to say :) It is indeed what some big
> >GNOME names have been advocating for. And I agree with it. At novell,
> >and I guess at other GNOME-related companies, we try to put as much
> >fixes as possible upstream, but for radical changes, it makes sense to
> >do them separately and merge them upstream if/when maintainers are ready
> >to accept it.
> >  
> >
> Sure it makes sense to develop radical changes on a branch rather than
> on the mainline, but this does not require secrecy.  Collaboration
> doesn't need to be restricted to mainline development.
> 
> Some of the benefits include:
> 
>     * Rather than dumping the change fully formed on the maintainer,
>       they might take an early peak at the code and tell you whether
>       there are problems with the design that would cause them to reject
>       the change later on.
>     * Reduce duplicated work: say someone else saw the mockups, decided
>       that they were a great idea and started implementing it.  What do
>       they do when they find out that you've also been developing the
>       feature.  What should the maintainer do if both groups submit
>       their respective patches for inclusion.
> 
> There definitely are benefits to secrecy (better signal/noise ratio
> between developers, being first to market with the feature), but they
> aren't all benefits to the community.
> 
yes, completely agree with you.

> >Also, current 6 months schedules make it difficult, at least from my
> >experience, to introduce big changes. For big things, you usually need a
> >couple of releases. Maybe we could improve this a little bit by
> >"forcing" people to branch as soon as we hit the freezes, so that big
> >changes can start immediately, instead of 2/3 months later (which is
> >mostly what happens now, that most people start branching a few weeks
> >after the final *.*.0 release).
> >  
> >
> Who says that a big change needs to be completed in 6 months?  For some
> changes it might make sense to skip a release, which also lets you
> continue working through the feature freeze.
> 
yes, that's ok for maintainers, but for outsiders, not really. There are
lots of feature-related patches in bugzilla waiting for maintainers to
branch.

> >Also, Federico suggested some time ago, IIRC, keeping the old stable
> >branches more alive than what they are right now. For instance, NLD10 is
> >based on GNOME 2.12, so it makes it impossible to introduce radical
> >changes in the upstream GNOME version, which is frozen. Of course, I'm
> >not saying we should allow companies to put whatever they want in old
> >stable releases, but maybe following Federico's suggestions would make
> >companies contribute better to upstream GNOME.
> >  
> >
> Would it have been possible to develop these changes as a public branch
> of the gnome-2.12 branch of the affected modules?  While the gnome-2.12
> branch is feature frozen, there is nothing stopping people from creating
> sub-branches.  This might also make it easier to merge the changes
> forward if they turn out to be good :)
> 
yes, also agree with you. I can say though that the changes are not as
radical as you might imagine. xgl/compiz is, of course, but this is
completely new material, and the new menu is not a patch to the panel,
but a separate applet, which can, I guess, easily be integrated into the
panel/desktop releases.

As for other changes, most are upstream in one form or the other.
Notifications (libnotify), login speedup improvements (g-c-c and
gnome-session), gnome-volume-manager, networkmanager, etc, etc
-- 
Rodrigo Moya <rodrigo gnome-db org>