Re: GEP discussion

[Alexander Larsson <alexl redhat com>]

On 23 Sep 2002, Michael Meeks wrote:

> Hi Alex / Havoc,
> 
> 	It seems to me the root of Alex's frustration - which is clearly worth
> addressing ( minor procedural issues aside ) is succinctly this:
> 
> On Sat, 2002-09-21 at 17:47, Havoc Pennington wrote:
> > Alexander Larsson <alexl redhat com> writes: 
> > > Basically, shit is not happening, and people get irritated. Can someone 
> > > PLEASE explain to me why doing a gep for thing like this is good?
> 
> 	So essentially you're complaining that it takes time to add hefty new
> APIs ?

A bit, but I can handle the delay. I just don't see what part of the GEP 
procedure is an improvement over normal public discusssions on the mailing 
list, like the first mail I sent out about the new API. That one at least 
generated some discussion.
 
> 	This is fairly crucial for any degree of API review to happen eg. - I
> havn't had time to read it yet [1].

I do agree that some caution is necessary when introducing new APIs, but I 
also think that the APIs need to go in so it can be used and possibly 
modified due to that experience. We can't expect new stuff to be perfect 
immediately.
 
> 	Furthermore, yes, the process is designed to delay API additions, and
> subject them to public comment before they go in. There is no
> fundamental reason that any other inter-locking API changes cannot be
> interleaved in GEP form with that - thus, it adds a net 1 week delay to
> any arbitrary set of new API inclusions.

I strongly object to calling our traditional procedure non-public. I'm 
sure there have been times when people have missed things going in and 
this has lead to problems, but I just don't see the impact GEP is 
supposed to have on this.

The only advantage is that lots of people are subscribed to the new 
gep-announce list and that way there might be a slightly lower risk of 
people missing the initial proposal. But if we go wild with lots of new 
GEPs that advantage will suffer too.
 
> 	This when contrasted with recent measured schedule slippage, is a tiny
> cost to pay [ IMHO ], compared with the great benefits of having this
> done publicly, and in a way such that people can comment.

Again. I've always been able to comment on lots of things in public 
before.
 
> > That is, what we'd want from a GEP here is:
> > 
> >  - getting changes on gep-announce so people don't miss them
> >  - giving people _some_ time to respond
> 
> 	The thing is that giving people time to respond seems to be the main
> problem that you have Alex - is that so ? I agree it's frustrating, but
> I think it's for the best in the long term.

It is frustrating. Especially when people are not responding much.

> 	The problem is, that based on previous mis-use of Action geps, I'm
> extremely cautious of them; people tend to like to have an "Adopt my
> code, even though I havn't written it yet, and here are my screenshots"
> Action GEP - rather than codifying the requirements before they hack,
> and submitting their final module to be tested against them.

The thing is, I could have spent a week codifying the requirements 
for icons and thumbnailing before starting, then have two weeks of 
pie-in-sky discussion about the requirements and peoples fantasies about 
the possibilities. Myself, I'd rather spend the little time I have writing 
code.

In essence, I can handle an action GEP where people can point out actual 
issues with my API and code, but if I had to do a requirements gep before 
I could even start coding I wouln't be very interested. 

I realize this is egoistic from my part, and that some decisions are 
better made early in the requirements process. It's just that I do a lot 
of the stuff I do because it is fun, and if we make the procedure to heavy 
it just won't be fun.
 
> 	Anyhow - quite possibly we could shorten the period of waiting if
> indeed, no-one contested a GEP after a shorter period - but, I'd hate to
> see more important things pushed through quickly like that.

I think a week of delay is ok if we don't do GEPs for smaller changes. 
What I think would be nice is to have some sort of recommendation on the 
magnitude of change that require a GEP, so we don't overuse them and make 
the project to heavy and slow.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a bookish Jewish boxer from the Mississippi delta. She's a 
transdimensional impetuous college professor from a secret island of warrior 
women. They fight crime!