Re: ARC & GNOME [Was: How we make decisions...]

[Havoc Pennington <hp redhat com>]

On Mon, 2004-11-29 at 17:37 -0800, Edward Hunter wrote:
> 
> After reading through some of the GEP documentation and discussion here are a
> few observations and questions that should help me understand things better.
> 
> The GEP process as defined in GEP-0 from 2002 seems to be more focused on the
> collection of product requirements than the discussion of architecture.

I think some history of GEP is probably in order. My memory is we
created the GEP process because there were a small number of huge
controversies that the community found itself unable to resolve. This
was due to personality issues and/or just major differences of technical
opinion. Different people would put different spin on it, but you get
the idea.

My take on things is that the GEP process really did not help with that,
and for areas without controversy (i.e. most areas and decisions)
everyone saw it as pointless. Thus the GEP idea failed. The big
controversies went away (the only one we have today is Java/C# and it
isn't nearly as bad as some of the historical fights) and things are
mostly running smoothly.

> Ultimately, the ARC question (as viewed inside Sun) comes down to where/how do 
> you capture interface related changes before they occur.  Once you have them 
> captured you can refer back to them later.  That's one of the prime things of 
> the Sun process.  Is this something you all want to get out of the GEP process 
> or is it captured somewhere else?

The official GNOME interface policy is that we don't change the public
interfaces. "Things intended to be public interfaces" is not as well-
documented as it should be, but would include for example GTK+ which
hasn't changed since 2.0. (Well, really it hasn't changed since 1.2,
since 1.2 interfaces are still there and working -
http://ometer.com/parallel.html)

> Sun currently spends a lot of time and energy trying to ensure that the GNOME
> stack is as stable as possible via our internal process.  We think it might be
> more beneficial to review the GNOME stack from this perspective directly with
> the community.  If Sun were willing to work within the GEP process and were
> able to provide resources towards improving interface stability, would this be
> of interest to the community.  We at Sun are thinking that this could be a
> better approach than Sun trying to address these issues independently and we
> are wanting to know if there is also a community interest in this area.

I think the community feeling is that the interfaces *are* stable.
That's at least the intent... while accidents do happen, said accidents
would normally be treated as bugs. If we take interface breaks as
accidents then the solution is really QA, rather than docs...

I've seen a number of references to concerns about interface stability
from Sun; I'm curious what the examples are. 

My guess is that you guys are worried about interface stability in
things we would not consider public interfaces. e.g. libwnck, or I would
argue that the applet interface isn't ready for ISV consumption.
In those cases, normally the solution would be writing code to bring
those interfaces up to supportable form or resolve the reasons we don't
feel we can commit to them.

I've been saying for years that libgnome/libgnomeui are busted and
shouldn't be recommended to ISVs; that's now being officially
acknowledged with the deprecation plan on them. But the interfaces won't
be broken, only deprecated, so if some ISV does use them they will keep
working.

Another area of work would be tools such as Sun's abicheck or the LSB
tools for verifying that ISVs use only supported interfaces...

Havoc