[aur-dev] [RFC] Per-user package submission and management

[Techlive Zheng]

On 14-01-10, Techlive Zheng wrote:
> As I suggested in a previous mail, the package evolution would be much
> more community driven if AUR allows user to submit its own varient of an
> "official" AUR package with the URL like [2], while the "official" AUR
> package stays at [1].
>
> [1]: http://aur.archlinux.org/packages/xyz
> [2]: http://aur.archlinux.org/account/john/packages/xyz
>
> Git Integration
> ---------------
>
> This functionality is similar to a Git fork on platforms like Github,
> but it is doable without Git. We can have this first, then consider the
> integration with Git.
>
> As I explained previously in another mail, it is really bad to support
> 'git push' for "offcial" AUR packages, (`git-push` for user's package
> varient is accetable, but it should have a lower priority), so the
> integration with Git is just simply to setup a read-only public Git
> interface for each package.
>
> Detailed Explaination
> ---------------------
>
> Each varient of the "official" AUR package should have its own votes.

One more thing about the votes is that user should be able to up-vote
and down-vote for a package varient, because a previously highly voted
package varient might turn up to dead someday, so it is important, its
votes could be decreased.

And the votes for an "offcial" AUR package could be caculated based on
the how many varients and downloads it has, it dose not have any actual
meaning other than to kown a package is hot or not. The name "votes"
might be changed to something else, like "ranks".

> On the "official" AUR package page, these varients as well as their
> votes should be listed, and sorted by the votes, so that user will have
> an alternative to try if the "official" one fails to build.
>
> The difference for a varient than the "official" one should be explained
> on the varient's page.
>
> The style of a user's package varient page should have obviously
> difference to the "offcial" AUR package page, or a notification message
> should be shown at the top to say something like "This package is not
> support by AUR community, use with caution!".
>
> With per-user package submission, we will have the follwing benefits:
>
> * Easy patch submission and maintainership management
>
>   * If an "official" AUR package is unmaintained for a while and the
>     maintainer is no longer active, someone who is willing to take over
>     the maintainership could submit its modifciation of the PKGBUILD as
>     his package first, then ask the AUR-GENERAL list for a review of his
>     PKGBUILD to ensure it is following the Arch's PKGBUILD standards,
>     and then TUs can assign him as the new maintainer to the "official"
>     AUR package.
>
>     This maintainership means the "official" AUR package will use his
>     source tarball since then. His personal package varient still exists
>     but will be hidden from the list on the "official" AUR package page.
>
>     (The technical detail depends on how this is implemented, it could
>     be a symlink to the maintainer's package directory on the filesystem
>     level, or a pure duplication of the maintainer's package sources, or
>     just an internal redirection to the maintainer's package varient for
>     the offcial package URL.)
>
>   * If the maintainer of an "offcial" AUR package is active, and
>     someone feels the "official" AUR package could be improved, he could
>     submit his modified PKGBUILD as his package first, then send the
>     maintainer a Patch Request, the maintainer could then do a review
>     to see if it is worth adopting.
>
>     We could implement a friendly web interface for this patch review
>     process.
>
>     If the maintainer accepts the patch, he could apply the patch on the
>     web interface or do it manually.
>
>     If the maintainer declines the patch, then the user could still
>     maintain it as a package varient if he wants, or ask the AUR-GENERAL
>     list for a disscution.
>
>     Of course, deletion permission for a user's package varient should
>     be granted to the user itself, he does not need to ask AUR-GENERAL
>     list for a deletion.
>
>     If consider the integration with Git, this should be implemented
>     similar to a Git Pull Request but simpler. For AUR, I do not think
>     we need something as complicated as Pull Request. Pull Request in a
>     platform like Github usually means a non-fastward merge with full
>     change history on both merge sides. We do not need detailed change
>     history, a new commit with final changes that makes our "official"
>     AUR package better is enought, so, "Patch Request" might be proper.
>
> * Better package outdate flagging mechanism
>
>   With per-user package submission, we could implement a better
>   outdate flagging mechanism.
>
>   When someone flags a package outdated, he needs to provide the
>   newest `pkgver` number. With this `pkgver` number, all varients of
>   this package will be checked and flagged if outdated.
>
>   On the "official" AUR package's page, only these updated package
>   varients will be shown, others will be marked in red and hided (needs
>   a clik to show).
>
> * Package deletion and merging handling
>
>   Package deletion and merging is only for "official" AUR packages.
>   User can keep and maintain what ever package varient he wants as his
>   own.
>
>   * If an "official" AUR package is deleted by TUs for some reasons
>     (proprietary software, un-standard naming convention, or being
>     merged into other package, etc), the entry for this package
>     (basically the name) should be kept in the database, as well as
>     the reason why it is deleted, so that when a user visits the page or
>     attempts to create it again, he will know why this package is not
>     supported by the AUR community. If he insists it is resonable to
>     create such a package, he could request it in AUR-GENERAL list for
>     TUs attention, or he can just maintain it as its own package, but no
>     AUR "official" version exists.
>
>     For package varients whose "official" version is deleted, a notable
>     notification should be alarmed at the top of varient's page, so that
>     the user will know this package is not supported by the community,
>     thus has no "official" version exists, and why, and what alternatives
>     are recommended to choose.
>
>   * If a never-existent package was created, then the "official" package
>     will be automatically created, and the maintainer is assigned to the
>     one who uploaded this package in the first palce.
>
> With per-user package submission, we could unify all the PKGBUILDs to
> AUR, easy to search, easy to review, absolutely community-oriented
> evolution for packages. (Currently, people store PKGBUILDs in all kinds
> of places, Github, Pastebin, and no integration with AUR.)
>
> Possible Cons
> -------------
>
> * Lots of package varients
>
>   Yes, but it is easier to keep the "official" one alive and updated,
>   and let the user's package varient die naturally, it does not matter.
>
>   For packages no one is willing to maintain, we can just remove the
>   maintainer and mark the "official" AUR package inactive and disable
>   the download. The PKGBUILD still can be found in the users' package
>   varient, just the AUR doesn't have a "official" one due to lacking
>   of a maintainer, until someone step in and take the responsiblity to
>   maintain it. We can deal with thousands of outdated, unmaintained
>   packages in AUR this way, nothing loss, nothing hurt.
>
> * More complicated AUR structure
>
>   Is it? I think it should be easy to people who use Linux, especially
>   Arch Linux, right?
>
> End Notes
> ---------
>
> This is some of my thoughts about how improves the AUR, comments and
> discussions are highly welcome. After all, I just to help making the
> Arch Linux better and better.