Re: RFP policy

[nils <n p sun com>]

Havoc,

I think this is a really good thing you're trying to do!

I just wanted to outline some differences between your proposal
and one that is commonly used at Sun; mainly because I think in a lot
of ways Sun is organizationally similar to GNOME and that perhaps
certain parts of the Sun process would be a good fit for the community
The process at Sun was specifically designed to allow developers to
develop freely and independently from one another, as long as they
followed a few rules like playing nicely with everyone else,
developing conflicting overlapping functionality, and not bringing the
whole system to its knees :-)

There are two separate bodies at Sun that review and approve a product
for release. The first body (called a steering committee) deals with
business and resource allocation issue (= all the political stuff).
The second body (called an architectural review committee aka ARC)
only deals with s/w architectural issues. The ARC tries to find out
things like if the software breaks other parts of the system, or that
api consistent and non overlapping in functionality with other APIs.
To give an example, architecturally there may be no problems shipping
a certain browser, developed by a certain large software company,
in Solaris (as long as it didn't conflict with Netscape), however,
from a business point of view that might not be such a good idea.

Now I'm not sure how things get decided (what's in GNOME, what's
in 5th Toe, what's not in any of the above), but it may be useful to have
those types of discussions decoupled from whether something is an
architecturally sound piece of software?

Secondly, in addition to what you propose, when a project comes to
review at Sun it needs to document each of its imported and exported
interfaces (and even some of its major private interfaces). Each
interface has a stability classification. I won't go into the details
now ( I will if asked) but some of the terms are:

Stable
Evolving
Unstable

The further down the software stack a product is the more
constraints will be placed on it, in order to insure that it doesn't break
other products that depend on it.

So if a programmer wants to use a particular interface, they can
look at the docs or man pages and see if this interface may potentially
change and break their program in some future release. By documenting
their imported interfaces at review time, this interface can be tracked.

I think a lot of this is implicitly the way things are done already in
GNOME, for example, GTK 2.0 is a major release; there are incompatible
interface changes between it and GTK 1.2, so if your app runs on GTK
1.2 you're going to have to do some work on getting it to work on 2.0.
Maybe all I'm suggesting that these kind interface stability get
documented (and by all means pick your favorite taxonomy) at
rfp review time?

Anyway if you like these approaches, let me know and we can try and
incorporate something into your proposal.

Nils


Havoc Pennington wrote:

> Hi,
>
> Glynn keeps bugging me to repost this; I was going to revise it a bit
> more extensively first, but I don't know when I'll get around to that,
> so I'll go ahead and try to restart discussion. I think I probably
> didn't incorporate all the comments people had last time; please
> re-comment as appropriate.
>
> The board was unanimously in favor of adopting some sort of policy for
> how we make technical decisions, though we didn't discuss the details
> much. But the first step in that is to try to get a good feel for what
> the policy should be like.
>
> The main alternative approach to this one would be some kind of
> technical review committee, I believe. If someone wants to write up a
> proposal along those lines for compare-and-contrast, it might be
> worthwhile.
>
> Anyway, my proposal is at:
>  http://pobox.com/~hp/policy.html
>
> Havoc
>
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers