Rename all GLEPs to .rst

1 files changed, 134 insertions, 0 deletions

diff --git a/glep-0035.rst b/glep-0035.rst
new file mode 100644
index 0000000..1644ab9
--- /dev/null
+++ b/glep-0035.rst
@@ -0,0 +1,134 @@
+GLEP: 35
+Title: Automated consistency check for ebuilds
+Version: $Revision$
+Last-Modified: $Date$
+Author:	Adrian Lambeck <adrian@basicsedv.de>,
+Status: Deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 12-Mar-2005
+Post-History: 12-Mar-2005
+
+
+Abstract
+========
+
+This proposal is meant to enhance productivity for Gentoo developers.
+It aims to reduce the number of trivial bugs by automatically detecting them
+through a consistency check that is performed before checking and on a regular
+basis through the whole tree.
+Why bother with trivial bugs when automated tests find them ?
+Save time and improve quality !
+
+
+Motivation
+==========
+
+When browsing `bugs.gentoo.org`_ you will find Bugs that take away a good
+amount of scarce developing time that could be used otherwise.  These are
+trivial bugs, i.e. wrong SRC_URI or cycles in DEPEND. Even worst - these bugs
+are sometimes reported several times so that they need to be marked as
+duplicates.  Bugs of that kind are easy to find and easy to fix. By using
+automatic checks on a regular schedule these bugs can be found.  Users have to
+be asked NOT to commit these bugs to `bugs.gentoo.org`_.  So there will
+(hopefully) be fewer bugs that need to be checked and assigned and they might
+get fixed faster.
+
+.. _bugs.gentoo.org: http://bugs.gentoo.org
+
+The Bugs found should be kept in an automatically generated list so that users
+can see that the problem has been caught and that it is being worked on.
+
+
+Specification
+=============
+
+Checks need to be performed for every ebuild.
+
+A report needs to be generated
+
+	- links to the specific problem need to be included
+	- reports need to be send to the groups responsible
+	
+Checks could be:
+
+	- cycles within DEPEND
+	- invalid SRC_URI
+	- "non-official" USE Flags
+	- Packages within DEPEND that are "*" for the arch specified
+	- broken shell scripts with invalid or missing commands
+	- inheritance of eclasses
+	- ...
+
+There might be other checks and tests that should be run
+that have not come to my mind yet. Also I might have suggested something that
+is not useful at all.
+
+If there are major problems (needs to be defined) within an ebuild a possible
+action could be to disable the ebuild (with ``"-*"``,)  perhaps, and send a
+mail to the maintainer.
+
+These kind of errors are not always the fault of the developers.
+
+There should be no compilation or something like that. If an ebuild fails to
+build somewhere then the user should file it as a bug as usual.
+
+
+Implementation
+==============
+
+The functionality described could be implemented in three ways:
+
+	1. On the developers machine ("client") where it is run before checking
+		only for the ebuilds that changed. (client does not fit here because 
+		the server and client should not communicate with each other at all)
+	
+	2. On the server where checks are run, i.e. once a week.
+	
+	3. On the "client" AND server 
+
+
+	Of course there are cons and pros (what came to my mind so far)
+	
+	1.
+		pro: 
+			- the tree can not become inconsistent in the first place (? see contra)
+			- once an ebuild is checked there is no need to do this again
+			- no dedicated machine necessary
+			- generate traffic only once on one machine
+			- errors that are caught here do not bother later on
+		
+		contra:
+			- the consistency is based on the tool installed 
+			 	(what happens when different devs use different versions ?)
+			- what happens when the ebuild layout changes and some ebuilds
+				do not get updated ?
+			 
+	2.
+		pro:
+			- Properties of other ebuilds might change that fit while writing an ebuild
+		
+		contra:
+			- the errors are found when the ebuild is already in CVS
+			- the whole tree needs to be checked
+			- possibly creates a lot of traffic on every run
+				(-> is there an FTP equivalent to HTTP`s HEAD ?)
+				
+	3. see 1. and 2.
+
+My favorite is 3 . All properties are checked before check-in and 
+the properties that change might be checked on a regular basis on the server.
+Only solution 3 brings the best from 1 and 2 together while delivering the best result.
+
+I never had a look at portage source but I can imagine that there is a library
+that has everything that a developer needs to "query" ebuilds. If not, this
+would be a reason for another GLEP (?).
+
+For performance I would use a database (on the server) to store the whole tree before
+running the checks. This is not necessary for the "client".
+
+
+Backwards Compatibility
+=======================
+
+Not a problem for this GLEP.