Re: Design by Community

[James Henstridge <james jamesh id au>]

Rodrigo Moya wrote:

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

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

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

James.