Re: GEPs

[Bill Haneman <bill haneman sun com>]

...
> > James Henstridge just pointed out to me that a clear GEP decision could have
> > avoided the zvt vs. vte fallout thread we had recently.
> 
> FWIW, I don't really feel that this is true. It would have (perhaps)
> made it harder to ignore what the module list was, but it was already
> pretty hard to ignore. I suppose if a GEP is just a way to cover our
> asses with people who don't pay attention to the lists, then yes, it
> would fill that role, but otherwise I don't see how it actually _solves_
> the zvt v. vte problem.

It would have formalized the decision and helped with communication,
*if* the GEP process wrinkles could be ironed out.

> 
> To put it another way: if the people involved don't want to agree (see:
> theme management) GEPs are just a more formal way for them to argue. It
> doesn't actually solve anything. 

I think this comment is unfair.  Calum and I were working hard to get
agreement on this topic.  I will say that the whole GEP thing (in
particular, the extent to which it was ignored when convenient to do so)
left a bad taste in my mouth, I am not eager to waste time^H^H^H^H^H^H^H
attempt to use the GEP process again.

- Bill

> Luis
> > A very good call, and a good reason to try it out with 2.4.
> > 
> > - Jeff

Michael's point was well-stated, I think:

> 
> 	Well - I think it is a way to cover your ass / assign collective blame
> ;-) but I think if people feel that their requirements have been
> listened to - and indeed people can present a reasoned case - that is
> archived in once place, then we're on a winner.

> 	I think it can also help motivate achieving closure on things like a11y
> if the prospect of 'official' inclusion is based on some requirements
> such as 'at least as good as libzvt' or somesuch.
> 
> 	Regards,
> 
> 		Michael.
-- 
Bill Haneman <bill haneman sun com>