Ciaran McCreesh wrote:
> | Which means you won't be able to satisfy your "preemptive"
> | requirement.
> 
> Not at all. You can warn users repeatedly, but there comes a point when
> trying to warn them any further becomes futile.

Then what is the point of this GLEP?  Instead, just warn people through 
existing intrastructure, which is cheap from an engineering perspective 
because everything is already there in place, and don't think of 
implementing all kinds of extras just to warn a user one extra time, 
since "trying to warn them any further becomes futile" anyway.

The motivation of your GLEP is based solely on the assumption that 
critical news is not effectively delivered to the user, however, the 
GLEP implicitly introduces this critical news, so how can it be ignored 
by users?  It's not there.

If you don't plan to solve the requirements you state yourself, either 
don't state them, or make clear you will not satisfy them for what 
reason.  To me it looks as if you just would like to remove the 
'preemptive' requirement because it suggests some behaviour that you 
don't (plan to) implement.  And hence, you should also rewrite the 
motivation to reflect your statement in the quote above.

I like the idea of the GLEP, since it will be helpful for many users I 
think, but the grounds on which and the reasons why should be valid 
points, IMHO.  I also think that the idea comes very close to things 
proposed and or desired by many users that would like to have all the 
einfo messages being sent out to them, or accumulated after portage has 
done it's compiling.  See the respective super bug and ml discussions on 
it.  Hence, the GLEP itself doesn't differentiate itself, is not defined 
to be generic enough or reusable, should include configurability and, 
last but not least as I mentioned before, should be grounded in valid 
points.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-dev@g.o mailing list