path: root/README
diff options
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)
Updated to rev2
Diffstat (limited to 'README')
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
+April 07, 2010
Project Grumpy
-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
+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)
+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
+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
+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