Date: Fri, 09 Jan 2009 18:33:38 +0100 Subject: [aur-general] Discussion period - Moving [community] to use same system as main repos From: Allan McRae To: "Discussion about the Arch User Repository (AUR)"
To get this moving along, I would like to start the official discussion period. Standard rules, 5 days discussion, 7 days voting, 75% quorum. If discussion raises some points which really need to be addressed before a vote then it can be delayed.
Abhishek has mad a good summary with some additions by Loui at http://wiki.archlinux.org/index.php/Community_move_to_devtools .
I have been thinking about the detriments and benefits and her are my comments:
- It might affect the autonomy of Trusted Users.
This is a big point to me. One very important reason for me to use Arch Linux is the existence of a great community contributing packages and the possibility to get them to a semi official repo in an easy way.
*and this is a big change from the way we've been used to.
That is true but only concerns our, the TU's, comforts. So it is not that important, we are all able to learn.
- The effort to make the transition happen is not trivial.
I cannot imagine how complicated it would be.
*You'd lose votes for community packages.
Well, we did just have a proposal in which one of the prerequisites for putting a package to [community] was the number of votes. Votes are also an indicator that users want a package to be kept in [community]. Strengthen the rule of votes in one proposal and weaken it in the next one is not an consistent attitude.
- You'd lose package comments and notifications.
This is also important to me. It is much easier to write a comment than to use a bugtracker for users.
- Combining community packages with official packages will contribute a
performance hit for all repos when dealing with >build files.
Cannot comment because i do not get the point.
<* There'll be fewer tools to support, since Trusted Users would then use the same tools as Arch developers, but with reduced permissions (only permission to write to the [community] repository)
This is a very minor point to me. I do not know how hard it is to maintain these tools, but is only a concern of very few people.
<* It'd be much easier to create and maintain a [community-testing] repository (or even the [testing] repository, if it's possible to cleanly separate the relevant permissions). A testing repository for [community] would be a great help in doing rebuilds.
I do not see that this is very important. I did not need such a repo up to now and most probably wont use it.
<* It'll be easier to migrate from being a Trusted User to a developer, since all the repositories would be using the same infrastructure. A simple permissions change, and they could be uploading packages to [core] or [extra].
I have absolutely no ambitions to becaome a developer. This point leads back to the first point under the "Detriments" section. If a TU wants to become a developer, he or she has do move his or her packages once, or even leave them in community, so the benefits are small. IMHO this point has to be moved to the "Detriments" section.
<* [community] would naturally become more decoupled from the AUR. Packages in [community] would become visible on the main Arch website, giving greater visibility to [community]. Also the search function on the website would then be able to search across all the repositories.
This is clearly a detriment to me.
< * The AUR code becomes greatly simplified, making code refactoring or rewrites easier.
< * The server daemon (tupkgupdate.py) for adding packages to [community] and other associated cruft which has been lying around for ages can be got rid of.
So in my opinion at now the benefits are small and the goals are not mine. A clear -1 from me.