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@gentoo.org mailing list
