summaryrefslogtreecommitdiff
path: root/README.txt
diff options
context:
space:
mode:
authoreric <eric>2004-06-13 18:15:49 +0000
committereric <eric>2004-06-13 18:15:49 +0000
commit569216db792249ba470a2371fc3ad72c79a567cd (patch)
treef6889d321013508dc647f1febce953820a5d09d8 /README.txt
parent36d0b810ad8de99337e3993de84087ae5878b2ec (diff)
initial import
Diffstat (limited to 'README.txt')
-rw-r--r--README.txt107
1 files changed, 107 insertions, 0 deletions
diff --git a/README.txt b/README.txt
new file mode 100644
index 0000000..12f64c7
--- /dev/null
+++ b/README.txt
@@ -0,0 +1,107 @@
+This is the finalized draft of the project requirements for the
+new Arch package submittal process. AUR (Arch User-community Repo).
+The sub-directories contain more specific implementation notes
+for each component of the project.
+
+
+Requirements:
+-------------
+1) User accounts (users, TUs)
+ - Create account. (email address required)
+ - Update account (change password/email address)
+ - Log in/out
+
+2) Search for packages (public)
+ - needs knowledge of ALL pkgs (OfficalRepos/AUR/Unsupported). This
+ should be easy enough if this site lives on the same machine as
+ the current package database (dragon?), or is allowed to query
+ the db.
+ - Display official repo (current/extra) a package lives in.
+
+3) Manual voting (requires user acct)
+ - reset/clear all votes (for starting over, this can be added later
+ if there is any demand for it)
+
+4) Package Management
+ - A package can be submitted by anyone (as long as they create
+ an account with a valid email address on the web site). From
+ there, a TU inspects the package and works with the submitter
+ to resolve any bugs/issues. Once approved, the TU can place the
+ package in the AUR. From there, if the package is popular enough
+ (or deemed necessary), a developer can move the package from the
+ AUR to extra/current/etc. A developer can also downgrade a
+ package from extra/current/etc to the AUR.
+ - The person that uploaded the new package can make changes to
+ it before it has been added to the AUR.
+ - TUs need to be able to purge packages in "Unsupported" if the
+ package is no longer maintained and there is no interest in
+ keeping it.
+ - Packages in the AUR/Unsupported need some sort of 'flag out of
+ date' support.
+ - Interested users can download the package from "Unsupported"
+ and build/install it by hand.
+ - Provide a separate installation of flyspray for tracking bugs
+ for packages living in the AUR. All bugs should be resolved
+ in either flyspray (AUR/official) prior to a package being
+ promoted/demoted.
+
+5) Reports
+ - package popularity by number of votes
+
+6) Wiki Docs (UID/GID db, provides db, irc nicks/names TUs/devs)
+ - Move the appropriate dev wiki pages to the new system's
+ wiki area. The devs will just need to consult the UID/GID
+ list from the new system site rather than our own wiki.
+
+7) Submitting 'new' packages by users. Initially start with
+ a simple web upload page where users submit a tgz containing
+ the PKGBUILD, scriptlets, patches, etc. The script will
+ unpack the tgz in an appropriate location and update the
+ backend database to 'register' the pacakge.
+
+8) TU package management
+ - A TU adopts a package from "Unsupported" and that shows users
+ and other TUs that the package is being reviewed.
+ - When the TU is ready to move the package to the AUR, they
+ use a custom utility/script that allows them to upload the
+ pkg.tar.gz (web uploads are inadequate for this process).
+ The upload utility/script has a server counterpart that
+ performs TU authentication and updates the database.
+ - A cronjob on the server can handle the new AUR package,
+ update the database, and rebuild the AUR sync db, and send
+ email notices to the TU about errors if any occur.
+ - The TUs should also be able to demote a package from the
+ AUR via the web interface.
+ - TUs will use cvs/svn interface (just like devs) to pull
+ down the PKGBUILD tree. This tree should reflect the same
+ layout as extra for easier package migration. They make
+ changes to their local copy, test, and then commit. They
+ use the xfer utility to upload the binary package to the
+ server. No shell access is required.
+
+
+Automated Voting Tool (similar to ArchStats client)
+=====================
+
+Requirements:
+-------------
+ 1) Name of tool is 'pkgvote'
+
+ 2) Requires registered account on web - email address not required
+
+ 3) Casts 'yes' votes for all installed packages (except itself?)
+
+Implementation:
+---------------
+ A statically compiled C program that gathers the list of installed
+ packages and casts the vote to the web site. Very similar to the
+ way that ArchStats works now. When making the HTTP Post, it adds
+ a custom HEADER that the PHP script(s) can detect to know that it
+ is receiving a vote from a 'pkgvote' client. If the PHP script
+ does not see the special HEADER, it assumes it is a web browser
+ and gives the user HTML output.
+
+ Once installed, the user edits the config file and supplies their
+ username/password. If no username/password exists in the config
+ file when it starts, it spits out an error message and exits.
+