aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorPriit Laes <plaes@plaes.org>2010-04-07 14:09:41 +0300
committerPriit Laes <plaes@plaes.org>2010-04-07 14:09:41 +0300
commit5633b0e2a3ed8227f86acf8a1faca2dc0a273cba (patch)
tree9f3f3edffc1a4dcf2e1a97caaad13c62880555a3 /README
parentImported doc. (diff)
downloadgsoc2010-grumpy-5633b0e2a3ed8227f86acf8a1faca2dc0a273cba.tar.gz
gsoc2010-grumpy-5633b0e2a3ed8227f86acf8a1faca2dc0a273cba.tar.bz2
gsoc2010-grumpy-5633b0e2a3ed8227f86acf8a1faca2dc0a273cba.zip
Updated to rev2
Diffstat (limited to 'README')
-rw-r--r--README147
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
++++++++++++++++++++++++++++