README.txt

   1 This is the finalized draft of the project requirements for the
   2 new Arch package submittal process.  AUR (Arch User-community Repo).
   3 The sub-directories contain more specific implementation notes
   4 for each component of the project.
   5
   6
   7 Requirements:
   8 -------------
   9 1) User accounts (users, TUs)
  10  - Create account. (email address required)
  11  - Update account (change password/email address)
  12  - Log in/out
  13
  14 2) Search for packages (public)
  15  - needs knowledge of ALL pkgs (OfficalRepos/AUR/Unsupported).  This
  16    should be easy enough if this site lives on the same machine as
  17    the current package database (dragon?), or is allowed to query
  18    the db.
  19  - Display official repo (current/extra) a package lives in.
  20
  21 3) Manual voting (requires user acct)
  22  - reset/clear all votes (for starting over, this can be added later
  23    if there is any demand for it)
  24
  25 4) Package Management
  26  - A package can be submitted by anyone (as long as they create
  27    an account with a valid email address on the web site).  From
  28    there, a TU inspects the package and works with the submitter
  29    to resolve any bugs/issues.  Once approved, the TU can place the
  30    package in the AUR.  From there, if the package is popular enough
  31    (or deemed necessary), a developer can move the package from the
  32    AUR to extra/current/etc.  A developer can also downgrade a
  33    package from extra/current/etc to the AUR.
  34  - The person that uploaded the new package can make changes to
  35    it before it has been added to the AUR.
  36  - TUs need to be able to purge packages in "Unsupported" if the
  37    package is no longer maintained and there is no interest in
  38    keeping it.
  39  - Packages in the AUR/Unsupported need some sort of 'flag out of
  40    date' support.
  41  - Interested users can download the package from "Unsupported"
  42    and build/install it by hand.
  43  - Provide a separate installation of flyspray for tracking bugs
  44    for packages living in the AUR.  All bugs should be resolved
  45    in either flyspray (AUR/official) prior to a package being
  46    promoted/demoted.
  47
  48 5) Reports
  49  - package popularity by number of votes
  50
  51 6) Wiki Docs (UID/GID db, provides db, irc nicks/names TUs/devs)
  52  - Move the appropriate dev wiki pages to the new system's
  53    wiki area.  The devs will just need to consult the UID/GID
  54    list from the new system site rather than our own wiki.
  55
  56 7) Submitting 'new' packages by users.  Initially start with
  57    a simple web upload page where users submit a tgz containing
  58    the PKGBUILD, scriptlets, patches, etc.  The script will
  59    unpack the tgz in an appropriate location and update the
  60    backend database to 'register' the pacakge.
  61
  62 8) TU package management
  63  - A TU adopts a package from "Unsupported" and that shows users
  64    and other TUs that the package is being reviewed.
  65  - When the TU is ready to move the package to the AUR, they
  66    use a custom utility/script that allows them to upload the
  67    pkg.tar.gz (web uploads are inadequate for this process).
  68    The upload utility/script has a server counterpart that
  69    performs TU authentication and updates the database.
  70  - A cronjob on the server can handle the new AUR package,
  71    update the database, and rebuild the AUR sync db, and send
  72    email notices to the TU about errors if any occur.
  73  - The TUs should also be able to demote a package from the
  74    AUR via the web interface.
  75  - TUs will use cvs/svn interface (just like devs) to pull
  76    down the PKGBUILD tree.  This tree should reflect the same
  77    layout as extra for easier package migration.  They make
  78    changes to their local copy, test, and then commit.  They
  79    use the xfer utility to upload the binary package to the
  80    server.  No shell access is required.
  81
  82
  83 Automated Voting Tool (similar to ArchStats client)
  84 =====================
  85
  86 Requirements:
  87 -------------
  88   1) Name of tool is 'pkgvote'
  89
  90   2) Requires registered account on web - email address not required
  91
  92   3) Casts 'yes' votes for all installed packages (except itself?)
  93
  94 Implementation:
  95 ---------------
  96   A statically compiled C program that gathers the list of installed
  97   packages and casts the vote to the web site.  Very similar to the
  98   way that ArchStats works now.  When making the HTTP Post, it adds
  99   a custom HEADER that the PHP script(s) can detect to know that it
 100   is receiving a vote from a 'pkgvote' client.  If the PHP script
 101   does not see the special HEADER, it assumes it is a web browser
 102   and gives the user HTML output.
 103
 104   Once installed, the user edits the config file and supplies their
 105   username/password.  If no username/password exists in the config
 106   file when it starts, it spits out an error message and exits.
 107