Updated to rev2

1 files changed, 90 insertions, 57 deletions

diff --git a/README b/README
index 28cc562..731ca2a 100644
--- a/README
+++ b/README
@@ -1,78 +1,111 @@
 Priit Laes
-March 28, 2010
-draft-project-grumpy-gsoc-1
+April 07, 2010
+draft-project-grumpy-gsoc-2
 
 Project Grumpy
 ==============
 
-Abstract
-++++++++
-Maintainers spend inordinate time doing chore works that could be automated.
-This project intends to do just that for them - automate and centralize a lot
-of that to save maintainers time and brain cells.
-
-Project Goals
-+++++++++++++
+Project Objective
++++++++++++++++++
 There are many moments in every package maintainers life when one wishes that 
 one or another thing would be done automatically for him/her:
-  * See what packages have a newer version available.
   * Check which packages have identified common QA issues.
-  * Generate stabilization list for number of applications.
-  * Get notified of that can be stabilized if following the 30-day guideline.
+  * Generate stabilization list for selection of packages.
+  * Get notified of packages that have new upstream versions.
+  * Get notifications of packages that can be stabilized if following the
+    30-day guideline.
 
-Many such automated or semi-automated software does exist, but they are
-currently dispersed across the Interwebs in various different locations, with
-typically no good connection between packages and the maintainer looking at
-the information. GPNL, tinderbox rindex/dindex reports, gentoo-bumpchecker,
-manual repoman/pcheck runs, and so on.
+Many such automated or semi-automated applications/scripts do exist, but they
+are currently dispersed across the Internet in various different locations,
+with typically no good connection between packages and the maintainer looking
+for the information. These applications include tinderbox rindex/dindex
+reports, gentoo-bumpchecker, manual repoman/pcheck runs, and so on.
 
 Project "Grumpy" is intended as a Gentoo Linux project to aggregate
 functionality of all these tools into one centralized application.
 
-High Level Diagram
-++++++++++++++++++
-
-  .-------.                 .-----------.
-  |Gentoo | .. Ebuild       |  Grumpy   |
-  |Portage|      Indexer .. |Application|
-  `-------'                 |  Backend  |
-                            `.---------.'           .----------.
-                             |   Web   |            |   LDAP   |
-                             |Interface|            |Gentoo.org|
-                          .-'`---------'          .-'----------'
-                   JSON .'            \         .'
-                 .'                    `.    .-'
-  .-----------..'                       .\.-:     
-  |Commandline| .................. Authentication 
-  |   Utils   |                                   
-  `-----------'
-
-Grumpy Component Overview
-+++++++++++++++++++++++++
+Abstract
+++++++++
+Project Grumpy is a set of applications for gathering, indexing and interacting
+with various ebuild- and developer-related metadata.
+
+Grumpy Component Overview (aka deliverables)
+++++++++++++++++++++++++++++++++++++++++++++
+This section gives an overview about the components and technologies that are
+going to be used for this project.
 
 Grumpy Application Backend
 --------------------------
 Grumpy Application backend is the core of the Grumpy Application. Backend
 handles data storage and indexing and consists of following components:
-  * Database for ebuild metadata storage
-  * Indexers for portage, upstream versions, bugzilla, etc
-
-Web Interface
--------------
-Web interface provides two basic features:
-  * User interface for developers to view and edit ebuild metadata
-  * Application interface for various tools to interact with metadata
-  via JSON-RPC protocol.
-
-Commandline Utils
------------------
-Commandline tools provide a way for developers manage package metadata on
-server from commandline.
-
-Development Plan
-++++++++++++++++
-TBD. This section contains dev plan of the project and includes low-level
-description of various technologies used for components...
+  * Database storage for ebuild metadata
+  * Tools for gathering and managing metadata
+	* Portage indexer
+	* Upstream information checks (version bumps, issues, etc)
+	* User-interface tools (Web interface, commandline utilities)
+
+Database
+~~~~~~~~
+Aim is to use document-oriented storage system (MongoDB) that allows easily
+store and query metadata in JSON-like data schema. MongoDB stands in a gap
+between key-value stores (Memcached) and traditional RDBMS (PostgreSQL, MySQL)
+systems. MongoDB also has facilities for advanced data aggregation options like
+Map/reduce, replication and fail-over support and auto-sharding, if ever needed.
+
+Tools for metadata management
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+There are basically three types of tools:
+  * Firstly, the tools that deal with low-level operations like keeping portage
+    contents in synchronization with database. For this part it is not clear
+	yet whether it is possible to use already existing software (Portage API or
+	pkgcore) or should it be implemented from scratch.
+
+  * Secondly the tools that are used to query outside information for ebuild
+    related information (upstream version bumps, bugzilla status, tinderbox
+	results). Implementing tools for this part also requires working together
+	with various parties in order to make sure we always get the up-to-date
+	data in format that can be easily understood by us.
+
+  * Thirdly, utilities that allow users (Gentoo developers) to maintain various
+    kinds of information they are interested in. For this purpose there are
+	mainly two types of utilities in mind: Web application providing both
+	HTML-based interface and JSON API. The latter can be used also for
+	various command-line utilities.
+
+
+Timeline and Development Plan
++++++++++++++++++++++++++++++
+It is quite clear that the most crucial part in this project is the data
+storage and portage indexer. When it is clear that contents in database
+can be kept in synchronization with Portage (this also includes package
+moves, slotting changes) then works on other parts like upstream indexers
+and web application can be started. Therefore I propose following tentative
+timeline:
+
+24. May: Official start of project
+  * Implement portage synchronization with database
+  * Implement 30-day stabilization checker
+  * Implement upstream version checker for GNOME project
+12. July: Mid-term evaluation submitting starts
+  * Inquiries on whether it's possible to use LDAP authentication for web app
+16. July: Deadline for mid-term student evaluations
+  * First sketches for JSON-API via web application
+  * Few simple commandline utils for developers to manage packages of interest
+9. August: Start of 'pencils down'
+20. August: Final evaluation deadline
+
+
+Biography
++++++++++
+I am an undergraduate student of theoretical physics in University of Tartu and
+my main research interest is cosmology and the nature of gravity.
+
+My leisure time mostly consists of working on various open-source or freelance
+projects, reading (either about physics or science-fiction) and spending time
+with friends.
+
+I have also held various positions in the past, including system administrator,
+embedded developer and web application developer.
 
 FUN: Origin of Grumpy's name
 ++++++++++++++++++++++++++++