two comments: 1) scheme uses something like this: "srfi" -- "scheme request for implementation". I've seen it in action: it seems to be 'great' in that the coder can get real, real busy coding, without getting trapped by the philosophical issues surrounding the design of the api. In a sense, you can go into 'pure code mode' and turn off your brain, or at least the part of the brain that hurts when one has to design from scratch. 2) the rfp idea works great when you have *two* classes of people involved in a project: experienced senior designers, and hot-shot super-coders. The designers are usually older, have seen the world, know how things should work, and are maybe burned-out on coding, or maybe can envision more than they can code in a lifetime. They love to write specs and argue the philosophy of API's. And then you need the young hot-shot coders who want nothing more than being in the coding-groove, and can implement a thousand-page spec in about a day. I think gnome has lots of the latter, and few of the former. Which is why the RFC question is getting ignored. You (we?) need to cultivate a class of spec writers that will e.g. add specs for SSL support in ghttp, and maybe document/extend what ever the hell is in glib. The spec writers/documentors are not yet a part of gnome; maybe they don't perceive the reward for thier efforts. --linas On Tue, Aug 21, 2001 at 01:46:37PM +0800, James Henstridge was heard to remark: > On Mon, 13 Aug 2001, Stephen Browne wrote: > > > 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? > > I am in favour of this sort of process, as long as it is used wisely. > > Blindly using it for every change will just make people think of them as a > hinderance rather than a helpful process. I am not sure what guidelines > should be used to decide when the process is appropriate though. > > Python uses a similar process (except they call them Python Enhancement > Proposals, or PEPs) and it seems to have been good way to handle > evolution of the language. One of the benefits is that everyone can see > what the proposed change will do. The PEP draft evolves through mailing > list discussion until it finally gets checked into CVS (or gets rejected). > > When it comes time to make a new release, the PEPs can serve as > documentation of the major changes in the release. > > For gnome, the RFPs could be used as a basis for whitepapers we might want > to put on the website for a release. > > James. > > > > > _______________________________________________ > foundation-list mailing list > foundation-list gnome org > http://mail.gnome.org/mailman/listinfo/foundation-list -- I'm very PUBLIC-MINDED, I'm helping a NIGERIAN get his $25,000,000 back!
Attachment:
pgprxUATAyQki.pgp
Description: PGP signature