Re: The nature of the Bonobo freeze.

[Maciej Stachowiak <mjs eazel com>]

Miguel de Icaza <miguel helixcode com> writes:

> I want to explain a bit more about the Bonobo API/IDL freeze.
> 

Miguel,

Thanks a lot for posting an explanation of the freeze. I'd like to
crrect a few minor factual errors in the below.

First, s/Eazel team/Nautilus team/; we have several non-Eazel Nautilus
contributors.

> 	When I came back, I found that Michael had reimplemented the
> 	UI handler, fixed the known problems, came up with a better
> 	design that satisfied the needs of everyone, except the ones
> 	of the Eazel team.

I don't think that is totally accurate. The new implementation he came
up with introduced many new problems; Nautilus happened to run into
the most because we had used the old UI handler the most heavily.
 
> 
> 	Michael got Nautilus to work with the compat layer on a
> 	branch.   The compat layer would obviously had the problems of
> 	the old compat layer plus any bugs in the new layer. 

I think it is an exageration to say he got it to work. It compiled but
the menus and toolbars were all wrong.

> 	If they wanted to keep the compat layer, they could have
> 	maintained it, but they demanded that Helix Code/Michael
> 	should develop and maintain this layer.

That's totally inaccurate. We didn't want a compat layer that we would
be the only ones to use, regardless of who maintained it. We wanted
either the old UI handler, or to move to the new API whole hog (which
we have now done).

> 	* What were the needs of the Eazel team?
> 
> 		The needs of the Eazel/Nautilus team was to have
> 		everything frozen, even if Bonobo was badly broken.

This is simply a misrepresentation. The old UI handler worked great
for what it did, and was much less buggy than the new UI handler is
even today. I agree that the new UI handler does provide for a bunch
of new feature possibilities and it is pointless ot roll it back.

> 		Parts of the negotiation were to get the people at
> 		Eazel to sign on fixing the basic pieces of Bonobo
> 		instead of forking Bonobo.

We never ever ever proposed, considered or raised the idea of forking
Bonobo. Or at least, if we had, I would have had a shit fit and quit
Eazel immediately.

> * When did Eazel demand the freeze?
> 
> 	Eazel has demanded a freeze for Bonobo since around early this
> 	summer.  Both their schedule for Nautilus has been delayed,
> 	both because of Bonobo and because of other components in the
> 	system. 

We did not "demand" a freeze, we asked for one and you promised
one. Also, the original people to call for a library API freeze for
GNOME 1.4 were members of the GNOME Steering Committee who don't work
for either Eazel or Helix; Eazel and Helix were following the request
of the steering commitee in agreeing to a freeze date.

> * Has Eazel frozen Nautilus, or are they just fixing problems related
>   to Bonobo?
> 
> 	No, Eazel has not feature frozen Nautilus yet as of today
> 	(October 21), so their schedule has slipped as well.  Maybe
> 	Bonobo is in large part responsible for the slip, but the new
> 	features are definetly not Bonobo's fault.

That is incorrect. Nautilus is feature frozen and has been since
September 5. At this point all we are doing is making bug fixes,
performance fixes, and usability tweaks to existing features, and have
deferred all additional feature work. Moving to the new UI handler is
part, but not all of this work. No one has claimed otherwise.

> 	Darin at Eazel actually realized that a hard freeze on the UI
> 	handler would be a bad thing both for Bonobo and for Eazel, so
> 	Darin, Michael and I agreed on having a soft freeze on those C
> 	interfaces until we were ready.

All we ever wanted was a Bonobo freeze except for changes needed to
fix bugs. No one ever wanted "no changes, not even ones you need to
fix bugs"; that is ridiculous.


> * What about shipping GNOME 1.4 with Bonobo 0.8, and later Bonobo 1.0?
> 
> 	The point has been brought up by various Eazel people: to ship
> 	with a set of Persist interfaces and Stream/Storage interfaces
> 	now, and later ship with either an incompatible set of
> 	interfaces, or renamed ones.
> 

I agree that having two different incompatible Bonobo releases as part
of the GNOME 1.x platform is not workable. However, changing
interfaces for GNOME 2.x is both workable and necessary.


> 
> * What remaining changes are there before Bonobo 1.0?
>

If the below are the only changes to be done for Bonobo 1.0, I am OK
with that (although that's just my opinion, and not Eazel's). Are you
willing to publicly commit to the changes below (plus ones needed to
fix bugs in Nautilus, Evolution, Gnumeric, and other Bonobo users) as
the only ones to go in for Bonobo 1.0?

I admit to some trepidation, since it's a longer set of changes than
the last one that was promised (only the studlyCaps change) but if you
promise publicly that this is the final list, I think that would make
the Nautilus team happy.

In addition, I'd like to ask you and Michael to create either a stable
branch or devel branch (doesn't matter which) so that development
changes other than this have some place to go in. I have a number of
API breaking cleanup type patches that I have not sent in out of
respect for the freeze, and I bet other people do too.

> 	* Use of studly caps for method naming and the renaming of
> 	  methods to use verb[Adjective]Noun. 
> 
> 		API breakage: CORBA IDL and the C API.
> 		Fixable by scripts. 
> 

[ I can't believe you still want to do this even after the huge flame
war where even the Sun guys said it was not that important. :-) But
it's true the people you negotiated with on behalf of the Nautilus
team did say this was OK. ]

> 	* XSync fix: There are a couple of race condition with X
>           events that can kill applications that use Bonobo
>           Controls/Bonobo Embeddables, and we need an extension to
>           make sure that we can sync the Async X queue and the sync
>           CORBA queue.
> 
> 		API breakage: none.
> 
> 	  This should be considered a bug fix.
> 
> 	* Support for Radio Toolbar buttons
> 
> 		API breakage: none.
> 
> 	  This shoudl be considered a bug fix.
> 
> 	* Anti aliases toolbar buttons (from Cody)
> 
> 		API breakage: none.
> 
> 	  Could be considered a bug fix, of feature that has no effect
> 	  on the API level, and can be easily backed out if required
> 
> 	* Stream/Storage fixes from Dietmar.
> 
> 		API breakage: small, but Nautilus would require a tiny
> 		patch that only removes a few lines (no new lines).
> 
> 	* Generic C Listener interface
> 
> 		No API breakage, as no application uses it.
> 
> 	* Property Bag API improvement.
> 
> 		No API breakage, only new entry points. 
>