Re: GEP discussion

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 <[email protected]> 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 ?

	This is fairly crucial for any degree of API review to happen eg. - I
havn't had time to read it yet [1].

	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.

	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.

	Thus - for upholding the principle that it shouldn't be the parties
with the vested interests that decide that something is "not
controversial", especially since backing such things out (once in) is
never likely to happen - it's best to go with the process for simple
things; thus I disagree with:

> I think your GEP as written, and for this specific situation, is
> clearly pointless. This is a combination of a) the particular changes
> aren't very controversial b) the GEP itself contains very little
> information.

	Quite possibly this should be an 'Action' GEP - "Move this API into
gnome-libs", quite probably that's my fault. I do believe it's pointfull
though.

> However just putting a largish API in libgnomeui with no public
> announce or rfc is not great.

	Quite.

> For this concrete case I think the right sort of GEP would be just the
> content of your original mail on the subject - "here is the API" and
> basically ask "any objections?" on the announce-only gep list, give
> people some time to object, and then record the change with rationale
> in the gep archive. Same thing you'd do on a mailing list, but commit
> it to CVS also.

	I'm happy with that - which is essentially an Action GEP.

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

>  - merging requirements/action GEPs, _but_ somehow still encouraging
>    people to write down requirements before they start quibbling about
>    code. I don't think we want two geps for everything. It's too
>    heavy.

	There is no need for 2 geps for everything; a requirements gep as I
recollect has two phases:

	a) Agreeing the requirements
	b) Agreeing the solution.

	Integrated into 1 GEP.

	So it seems to me that there are two problems:

	a) a feeling of sluggishness
	b) using a requirements instead of an action GEP.

	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.

	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.

	Also; wrt this particular GEP, I'd be most interested in Owen's
comments, as to the long term direction; whether such a thing
could/would be folded into Gtk+, and whether he envisages any problems
with the API such that it couldn't become a wrapper for a future gtk+
version.

	Anyway; some points for thought perhaps,

	Regards,

		Michael.

[1] - not that that is any yardstick of quality of course ;-)
-- 
 [email protected]  <><, Pseudo Engineer, itinerant idiot