Add feedback

1 files changed, 26 insertions, 2 deletions

diff --git a/users/antarus/projects/gleps/glep-XX.txt b/users/antarus/projects/gleps/glep-XX.txt
index c9a1810961..61bdd6ffe5 100644
--- a/users/antarus/projects/gleps/glep-XX.txt
+++ b/users/antarus/projects/gleps/glep-XX.txt
@@ -13,8 +13,7 @@ Abstract
 ========
 
 This document proposes a new kind of eclasses, which are specific to a certain
-package (hence "per-package eclasses"). It explains the current need for
-package specific eclasses, the proposed solution and a possible migration path.
+package (hence "per-package eclasses").
 
 What is proposed is, in short, creation of eclasses in package directories for
 use by the ebuilds of the package in the same directory. Per-package eclasses
@@ -39,6 +38,21 @@ clutter in the current eclass directory, provide a single directory to
 understand an ebuild and provides security benefits by including the eclasses in
 the Manifest file.
 
+<!-- ANTARUS
+Editors Note
+The document fails to explain how these problems will be solved.  For
+instance, how will per-package eclasses reduce the total number of eclasses in
+/eclass?  The data show that the number of eclasses will be reduced by
+three (mysql, php, and nvidia-drivers.)  This is not a compelling argument.
+
+How do per-package eclasses make overlay usage easier?  If a user is working
+on a package and the package has a per-package eclass in tree already, how is
+that any different from the current situation (over-riding an eclass in
+/eclass vs over-riding a per-package eclass.)  The only gain seems to be in
+limiting eclass scope.  Editing a per-package eclass means only one package is
+affected.
+-->
+
 Specification
 =============
 
@@ -78,6 +92,16 @@ regenerating Manifests in a specific package directory. It is assumed that
 whoever changes functionality in a package also uses tools capable of supporting
 features used in the package's ebuilds.
 
+<!-- ANTARUS
+Editor Note:
+What happens when an old version of portage encounters a manifest entry it
+does not recognize?  How will these manifests be generated?  What kind of
+entries?  What kind of checksums?  The GLEP omits all of this information.
+
+How long will it take to implement these manifest tools?  How long must
+clients wait if PMs die on unknown manifest types?
+-->
+
 Copyright
 =========