Re: GEP discussion
Alexander Larsson <[email protected]> Mon, 23 Sep 2002 06:01:30 -0400 (EDT)
| Newsgroups | gmane.comp.gnome.lib.devel,gmane.comp.gnome.foundation.general |
|---|---|
| Message-ID | <Pine.LNX.4.44.0209230530530.26936-100000@devserv.devel.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 <[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 ? 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 [email protected] [email protected] 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!