Re: Design by Community

[Rodrigo Moya <rodrigo gnome-db org>]

On Wed, 2006-02-08 at 11:01 +0100, Christian Fredrik Kalager Schaller
wrote:
> On Wed, 2006-02-08 at 15:36 +1100, Jeff Waugh wrote:
> > <quote who="Dan Winship">
> > 
> > > But it seems to me now that everyone other than me (and possibly Jono) is
> > > actually talking about Xgl, and I have no comment on that.
> > > 
> > > (OTOH, if you really were saying that Novell's writing a replacement for
> > > the panel menu was "commons-sapping, community-tearing, morally and
> > > intellectually lazy", then by all means, let me know so I can write a
> > > suitably rude reply. :)
> > 
> > I was not talking exclusively about Novell, Xgl, or the new panel applet. I
> > was talking about a serious problem in our community, and the destructive
> > ideas, memes and role models that support it.
> > 
> 
> 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.

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

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.

> There is also a lot that gets thrown away, and I guess people don't want
> to spend time discussing UI and so on about something which might not
> ever get used outside their own machine, for instance someone mentioned
> the Novell Network applet, which afaik ended up in the dustbin and
> Novell started contributing to NetworkManager instead. 
> 
> That said I think the 'problem' of endless debates on desktop-devel in
> regards to actual development is overstated. 90% of endless debates on
> this list is not about module xyz, but about general policy issues like
> this one.
> 
> If we want to get (back) to a situation where more gung-ho stuff happens
> in our core modules I think we need to do a couple of things. Like
> increase module maintainers freedom again (at the cost of the release
> team for instance) and accept that if radical changes happens to module
> XYZ the maintainer of that module is more free to ignore any criticism
> no matter who is giving it. So if the Nautilus maintainers decide that
> file manager windows should be circle shaped and not square for instance
> the rest of us have to accept that.
> 
that's basically how it works already :) Maintainers do changes, and
when those changes upset people, they complain (ie, see background
capplet instant-apply removal). So, except during freeze times,
maintainers have freedom to do what they want in their modules. The
problem with big changes is on modules the person doing the big change
doesn't maintain.
-- 
Rodrigo Moya <rodrigo gnome-db org>