Re: RFP policy

[Stephen Browne <Stephen Browne sun com>]

Hi,

I just wanted to add that I agree that some kind of process like this 
could be valuable, however since there has been next to no response to
Havoc's proposal since he sent it out, I'm thinking Hackers really don't
want this.

There weren't even any comments from other board members (AFAIK) who
were supposed to be all for adopting some kind of RFP.

Is this all just going to /dev/null or is anyone going to comment on the
proposal?

Knowing the internal ARC procedure from SUN, it can be quite time consuming
and it feels like a chore that takes you away from stuff you really want to
be doing and this may be why people are hesitant to pick up on this.

I also understand and appreciate the benifits it brings and even though I
hate filling in forms and taking time to classify and write up APIs it saves
time for everyone in the long run.

I kinda like Havoc's proposal because its simpler than SUN's and should take 
less time to go through :)

Its not going to work if people arent behind it though so can we start saying
'yay' or 'nay' to this sometime soon?

Stephen. 



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