Re: About GNOME 2.0 - The end of a dream

[Daniel Veillard <veillard redhat com>]

On Sun, Jun 17, 2001 at 03:21:19PM +0200, Dietmar Maurer wrote:
> Daniel Veillard wrote:
> 
> > > The above statement give the impression that we have made some massive code
> > > duplication, which is simply not true.
> >
> >   This is not the point.
> > Do you agree that we should have a formal process to get a new piece of code
> > added to the Gnome platform:
> >    - yes
> >    - no
> >
> >   Don't make convolution around it, it's the real question at stake !
> 
> I disagree, we do not need an formal process if someone writes a new bonobo Moniker,
> because I think that we already agreed to use bonobo. So what piece of code your are
> talking about? We have added nothing to the Gnome platform, only reused the existing
> PropertyBag interface and Monikers.

  Basically the decision was to remove GConf. 

s/get a new piece of code added to/change the design/

> Such decisions can be taken by the people actually working on the code. And
> everybody is able to see what those people are doing, because we use CVS. We can
> even revert changes if someone made a bad decision, due to the use of CVS ;-)

  I will take a similar example to show you that is not that simple....

  Okay, since libxml is in CVS you know where it had been going since libxml1
was forked. Good, I know at least one person won't have troubles switching to
libxml2. And since those are discussed in the xml gnome org (of course I know
nobody from Ximian/Redhat/Eazel ever subscribed to this list, except Jacob
when he was still using his university address) I can argue that you were all
aware where libxml2 was going for all this time, and protest if anyone 
argue that something has changed.

  I'm a coder too, and I also went through a lot of process in my previous
job, so I know how much it can be a pain to follow a process. But stating
before hand where development is heading, how it is supposed to be achieved,
how long it is supposed to take, and negociating if necessary at the planning
stage with the other projects depending on it is necessary if we want to go
forward without loosing people, focus or the community sense.

> Using a formal process only removes the responsibility from the maintainer,

  No it makes him responsible for following the plan, i.e. give him more
weight actually. If the gconf change had been planned before hand then Martin
very simple answer would have been "we decided this, this was the plan",
and he would have been in a far better position to defend himself.
In fact nobody would have objected at that point, and this accident would
not have happened.

> and I
> think this will block the whole development.

  Maybe your experience and my experience of large number of cooperating
teams working toward a given direction are different.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Sep 17-18 2001 Brussels Red Hat TechWorld http://www.redhat-techworld.com