aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorPriit Laes <plaes@plaes.org>2010-04-08 19:25:56 +0300
committerPriit Laes <plaes@plaes.org>2010-04-08 19:25:56 +0300
commitf098c24deb311bc0e4e9ef6cc7e764ac56b5797b (patch)
treeb0d280a95b1078d95fbf4514c764bf07b11d2723 /README
parentUpdated to rev2 (diff)
downloadgsoc2010-grumpy-f098c24deb311bc0e4e9ef6cc7e764ac56b5797b.tar.gz
gsoc2010-grumpy-f098c24deb311bc0e4e9ef6cc7e764ac56b5797b.tar.bz2
gsoc2010-grumpy-f098c24deb311bc0e4e9ef6cc7e764ac56b5797b.zip
Style fixes.
Diffstat (limited to 'README')
-rw-r--r--README49
1 files changed, 24 insertions, 25 deletions
diff --git a/README b/README
index 731ca2a..47a5d75 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
Priit Laes
-April 07, 2010
-draft-project-grumpy-gsoc-2
+April 08, 2010
+draft-project-grumpy-gsoc-3
Project Grumpy
==============
@@ -10,7 +10,7 @@ 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:
* Check which packages have identified common QA issues.
- * Generate stabilization list for selection of packages.
+ * Generate a stabilization list for the 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.
@@ -22,7 +22,7 @@ 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.
+the functionality of all these tools into one centralized application.
Abstract
++++++++
@@ -40,43 +40,43 @@ Grumpy Application backend is the core of the Grumpy Application. Backend
handles data storage and indexing and consists of following 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)
+ * 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.
+The aim is to use document-oriented storage system (MongoDB) that allows easy
+storing and retrieval of 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.
+ contents in synchronization with database. For this part it is not yet clear
+ 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.
+ 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 a format that can be easily understood by our tools.
* 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.
-
+ 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
+storage and portage indexer. When it is clear that contents in the 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
@@ -94,7 +94,6 @@ timeline:
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
@@ -105,7 +104,7 @@ 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.
+embedded software developer and web application developer.
FUN: Origin of Grumpy's name
++++++++++++++++++++++++++++