Difference between revisions of "AUR Trusted User Guidelines"

From ArchWiki
Jump to: navigation, search
(TODO list for new Trusted Users)
(Added important quote (TU mission statement))
Line 29: Line 29:
* If you are not upgraded to a Trusted User group on bugtracker in two days, report this as a bug to Roman
* If you are not upgraded to a Trusted User group on bugtracker in two days, report this as a bug to Roman
* Start contributing!
* Start contributing!
==The TU's mission statement==
On Sunday, 5th September 2010, [http://mailman.archlinux.org/pipermail/aur-general/2010-September/010649.html Sven-Hendrik Haase wrote]:-
:Arch TUs are generally considered to be the ultimate nightmare of any upstream maintainer. We come in the night, nagging with patches until all known upstream problems are fixed.
:Do not stop trying to get your patches into upstream.
==The TU and [unsupported]==
==The TU and [unsupported]==

Revision as of 15:26, 6 September 2010

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.

Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어

External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end

The Trusted User (TU) is a member of the community charged with keeping the AUR in working order. He/she 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.

The TUs are governed using the TU bylaws

TODO list for new Trusted Users

  • Install the devtools package.
  • Send an email to Loui Chang with one ssh public key attached. If you don't have one, use ssh-keygen to generate. You can check the Using SSH Keys wiki page for more information about creating ssh keys and setting up an ssh-agent to use them.
  • Make the directories ~/staging/community and ~/staging/community-testing on aur.archlinux.org. This step is important as the devtools scripts use this directory to process incoming packages.
  • Remind Allan to change your account on forums
  • Make sure your sponsor has given you TU status on the AUR
  • Ask some TU for the #archlinux-tu@freenode key
  • Send Aaron Griffin all the information based on this template to have access on dev interface
  • Add yourself to the Trusted Users page
  • Read the Trusted User Guidelines.
  • If you are not upgraded to a Trusted User group on bugtracker in two days, report this as a bug to Roman
  • Start contributing!

The TU's mission statement

On Sunday, 5th September 2010, Sven-Hendrik Haase wrote:-

Arch TUs are generally considered to be the ultimate nightmare of any upstream maintainer. We come in the night, nagging with patches until all known upstream problems are fixed.
Do not stop trying to get your patches into upstream.

The TU and [unsupported]

The TUs should also make an effort to check package submissions in UNSUPPORTED for malicious code and good PKGBUILDing standards. In around 80% of cases the PKGBUILDs in the UNSUPPORTED are very simple and can be quickly checked for sanity and malicious code by the TU team.

TUs should also check PKGBUILDs for minor mistakes, suggest corrections and improvements. The TU should endeavor to confirm that all pkgs follow the Arch Packaging Guidelines/Standards and in doing so share their skills with other package builders in an effort to raise the standard of package building across the distro.

TUs are also in an excellent position to document recommended practices.

The TU and [community], Guidelines for Package Maintenance

Rules for Packages Entering the [community] Repo

  • Only "popular" packages may enter the repo, as defined by 1% usage from pkgstats or 10 votes on the AUR.
  • Automatic exceptions to this rule are:
    • i18n packages
    • accessibility packages
    • drivers
    • dependencies of packages who satisfy the definition of popular, including makedeps and optdeps
    • packages that are part of a collection and are intended to be distributed together, provided a part of this collection satisfies the definition of popular
  • Any additions not covered by the above criteria must first be proposed on the aur-general mailing list, explaining the reason for the exemption (e.g. renamed package, new package). The agreement of three other TUs is required for the package to be accepted into [community]. Proposed additions from TUs with large numbers of "non-popular" packages are more likely to be rejected.
  • TUs are strongly encouraged to move packages they currently maintain from [community] if they have low usage. No enforcement will be made, although resigning TUs packages may be filtered before adoption can occur.

Accessing and Updating the Repository

The [community] repository now uses devtools which is the same system used for uploading packages to [core] and [extra], except that it uses another server http://aur.archlinux.org instead of http://archlinux.org. Thus most of the instructions in Packager Guide work without any change. Information which is specific for the [community] repository (like changed URLs) have been put here.

Initially you should do a non-recursive checkout of the [community] repository:

svn checkout -N svn+ssh://aur.archlinux.org/srv/svn-packages

This creates a directory named "svn-packages" which contains nothing. It does, however, know that it is an svn checkout.

For checking out, updating all packages or adding a package see the Packager Guide.

To remove a package:

ssh aur.archlinux.org /arch/db-remove pkgname community arch

Here and in the following text, arch can be one of i686 or x86_64 which are the two architectures supported by Arch Linux. (What about "any"?)

When you're done with editing the PKGBUILD, etc, you should commit the changes (svn commit).

When you want to release a package, first copy the package to the staging/community directory on aur.archlinux.org using scp and then tag the package by going to the pkgname/trunk directory and issuing archrelease community-arch. This makes an svn copy of the trunk entries in a directory named community-i686 or community-x86_64 indicating that this package is in the community repository for that architecture.

Note: In some cases, especially for community packages, an x86_64 TU might bump the pkgrel by .1 (and not +1). This indicates that the change to the PKGBUILD is x86_64 specific and i686 maintainers should not rebuild the package for i686. When the TU decides to bump the pkgrel, it should be done with the usual increment of +1. However, a previous pkgrel=2.1 must not become pkgrel=3.1 when bumped by the TU and must instead be pkgrel=3. In a nutshell, leave dot (.) releases exclusive to the x86_64 TU's to avoid confusion.

Thus the process of updating a package can be summarised as:

  • Update the package directory (svn update some-package)
  • Change to the package trunk directory (cd some-package/trunk)
  • Edit the PKGBUILD, make necessary changes and makepkg. It is recommended to build in a clean chroot.
  • Namcap the PKGBUILD and the binary pkg.tar.gz.
  • Commit, Copy and Tag the package using communitypkg "commit message". This automates the following:
    • Commit the changes to trunk (svn commit)
    • Copy the package to aur.archlinux.org (scp pkgname-ver-rel-arch.pkg.tar.gz aur.archlinux.org:staging/community/)
    • Tag the package (archrelease community-{i686,x86_64})
  • Update the repository (ssh aur.archlinux.org /arch/db-update)

Also see the Miscellaneous section in the Packager Guide. For the section Avoid having to enter your password all the time use aur.archlinux.org instead of archlinux.org and svn.archlinux.org.

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.

Moving packages from unsupported to [community]

Follow the normal procedures for adding a package community, but remember to delete the corresponding package from unsupported!

Moving packages from [community] to unsupported

Remove the package using the instructions above and upload your source tarball to the AUR.

Deleting packages from unsupported

There's no point in removing dummy packages, because they will be re-created in an attempt to track dependencies. If someone uploads a real package then all dependents will point to the correct place.

For an example of a dummy package see: http://aur.archlinux.org/packages.php?ID=23600