From 73f807a5a86c3ebd2f2de84b721c78271bd0cace Mon Sep 17 00:00:00 2001 From: Loui Chang Date: Tue, 19 Aug 2008 18:10:29 -0400 Subject: Remove obsolete Trusted User guidelines. Guidelines are now maintained in the Arch wiki. Signed-off-by: Loui Chang --- web/html/guidelines.html | 273 ----------------------------------------------- 1 file changed, 273 deletions(-) delete mode 100644 web/html/guidelines.html diff --git a/web/html/guidelines.html b/web/html/guidelines.html deleted file mode 100644 index c2acd772..00000000 --- a/web/html/guidelines.html +++ /dev/null @@ -1,273 +0,0 @@ - -AUR Guidelines - - - - - - - -

AUR Guidelines

- -
Jun 08, 2005
-
1.1.0
- -
- Ben Mazer - -
-
- The Trusted Users - -
- -

Summary

-

- Basic guidelines for the Arch User Repository. -

- -

Table Of Contents

-
-
    -
  1. Purpose
    2. -
  2. The User -
      -
    1. Submitting Packages
      2. - -
    -
    3. -
  3. The TU -
      -
    1. Adding a TU
      2. -
    2. Removing a TU
      3. -
    3. Other Duties
      4. -
    4. Guidelines for Package Maintenance -
        -
      1. Accessing the Repo
        2. -
      2. Adopting a package
        3. -
      3. Disowning a package
        4. -
      4. Packaging Etiquette
        5. -
      -
      5. - - -
    4. -
  4. Frequently Asked Questions
    5. -
-
- -

Purpose

-

- The AUR -is a community of Arch users, where packages outside of the core Arch -distribution are maintained. The AUR Community Repo is a supplement to -the EXTRA and CURRENT repositories; less popular packages will be -maintained as a service to the general Arch-using population. Packages -in the AUR will depend on EXTRA and CURRENT.

The AUR was -created to lift the burden on the developers. They should be allowed to -focus on adding new features, rather than doing the mundane job of -package maintenance. Therefore, all packages start inside the AUR, and -as developers consider them crucial to the distribution, they will be -adopted into EXTRA/CURRENT. The AUR was also created to allow easy -participation. Arch is completely volunteer-based, and needs help from -its users. Lastly, the AUR helps to further the Arch philosophy of -KISS. The Arch Core (EXTRA/CURRENT/UNSTABLE) is a complete -distribution, but it does not attempt to provide every single package. -The AUR helps by maintaining less popular packages; but the AUR also -follows KISS, and only popular packages from UNSUPPORTED will make it -into the official AUR repository.

-

The User

-

Users of the -AUR can do many things, the main function being to download and use -packages. One can access the AUR by adding this to their pacman.conf -file:

- [community]
Server = ftp://ftp.archlinux.org/community/os/i686/

-But a user can also help with package maintenance, by: submitting -packages (and then maintaining them while they remain in UNSUPPORTED), -filing bug reports, reporting out-of-date packages, helping with other -user-submitted PKGBUILDs, and voting for packages that should be -maintained by the TUs. Once a user account has been created, all -functions can be performed inside the web interface.

Submitting Packages

-

-Inside the web interface, a user can submit a tarball (tar.gz) of a -directory containing build files for a package. The directory inside -the tarball should contain a PKGBUILD, any .install files, patches, etc -(no binaries). Examples of what a directory looks like can be seen inside /var/abs.

- When submitting a package, observe the following rules: -

- - -

The TU

-

-The TU -or Trusted User- is a member of the community charged with -keeping the AUR in working order. He maintains popular packages, and -votes in administrative matters. A TU is elected from active community -members by current TUs in a democratic process. TUs are the only -members who have a final say in the direction of the AUR.

-

Adding a TU

-

-TUs are only added as needed, and applications will only be accepted at -certain times. Check the AUR website for details on whether -applications are being accepted.

-TUs are elected democratically. If you would like to become a TU, a -sponsor (another TU) is needed. You must solicit requests for a sponsor -privately before posting on the mailing list. After this is received, a -request must be made on the AUR Mailing List by the sponsor. Ideally, a -TU should have a specific subset of packages he wishes to maintain.

-Four other votes must be received from other TUs or developers for an -applicant to be accepted. Once these have been received, the user will -be given the proper passwords, and a TU will upgrade the user's status -on the web interface.

-Once an application has been published on the mailing list, it is open -for voting for 3 weeks. If the applicant does not receive enough votes -within that time period, he must wait 3 months to submit another -application, with vote tallies being reset.
- -

-

Sanctioning/Removing a TU

-

-There is a basic sanctioning system for TUs. If a TU breaks a rule, -either official or through "community standards" when he was already -aware of this rule, one can request a sanction. If two other votes from -TUs are received, a sanction will be added. After two sanctions, the TU -will automatically come up for a removal vote.

If a TU is not working out, for any reason, one can -request him to be expelled. Someone requesting a removal of a TU must -state a valid reason, and why immediate removal is necessary. Almost -always, previous sanctions will be needed. With four additional votes, -that TU will be immediately removed and his packages will have to be -adopted by a different TU.

-

Other Duties

-

-All other duties (changing rules, adding new regulations, new features, -etc) should be discussed openly on the AUR Mailing List and voted on. -Various pieces of documentation and code can have specified -"maintainers" that can perform basic updates (typo/bug fixes) without a -vote, but any changes should be reported on the mailing list. Any major -changes should receive a simple majority vote.

-

Guidelines for Package Maintenance

-

-

-

Accessing the Repo

-

- Follow these instructions for uploading/modifying packages once you have become a TU: -

    -
  1. Install the "aurtools" package.
    2. -
  2. Email Jason () for a CVS account.
    3. -
  3. Run the following commands to checkout the AUR CVS:
    - - export CVSROOT=":pserver:<userid>@cvs.archlinux.org:/home/cvs-community"
    - cvs login
    - cvs co community
    4. -
  4. To add a PKGBUILD and other build files:
    - - cvs add <directory>
    - cd <directory>
    - cvs add PKGBUILD
    - .
    - .
    - cvs commit
    5. -
  5. To upload a binary package: - tupkg --user <userid> --password <password> <packagefile.pkg.tar.gz>
    6. -
  6. After uploading a package and committing the build files, tag the files with this command: - cvs tag -cFR CURRENT <newpackagebuilddir>
    7. -
  7. Package -changes should be available within 10 minutes. Verify everything was -uploaded properly, then select the newly added or updated package in -the web interface and set yourself as the maintainer.
    8. -
- -

Adopting Packages

-

-A TU may adopt any package at any time. But because the TU's time is -limited, he should try to only adopt popular packages. The voting -mechanism in the AUR allows a TU to quickly gage which packages users -want.

-If a package receives 25 votes, it may be adopted by a TU. A maintainer -should adopt it via the web interface. That maintainer is then -responsible for bug fixes and new version updates. Packages must be -properly cleaned and fixed after adoption.

- -

Disowning packages

-

-If a TU can't or doesn't want to maintain a package any longer, a -notice should be posted to the AUR Mailing List, so another TU can -maintain it. A package can still be disowned even if no other TU wants -to maintain it, but the TUs should try not to drop many packages (they -shouldn't take on more than they have time for). If a package has -become obsolete or isn't used any longer, it can be removed completely -as well.

-If a package has been removed completely, it can be uploaded once again -(fresh) to UNSUPPORTED, where a regular user can maintain the package -instead of the TU.

-

Packaging Etiquette

-

- Adhere to the following rules when building/maintaining packages: -
-

- -

Frequently Asked Questions

-

- Q: What is the difference between the AUR, COMMUNITY, and TUR? Why don't packages I upload to the AUR show up in pacman?

-A: The TUR, or Trusted User Repository, was the old system used to -manage user submissions. It had a number of flaws, so was discontinued. -The TUR website is still up, but is dead and will be removed shortly. -AUR is the official replacement for the TUR. It is a web system that -allows users to submit their own PKGBUILDs for both the TUs and the -general community to see. COMMUNITY is a new Arch repository, run by -the TUs, that is available via pacman.

-User submitted PKGBUILDs are available from the AUR, but because they -have not been reviewed, packages are not available. If a PKGBUILD is -reviewed, and receives many votes, it may "graduate" into the COMMUNITY -repo. There it will easily be retrievable from pacman.

-If you are a new user, it is safe to use the COMMUNITY repo, as -packages have been verified. Any PKGBUILDs in the UNSUPPORTED section -of the AUR have not been tested, and could be dangerous or broken. Use -at your own risk.

- -- cgit v1.2.3-24-g4f1b