[aur-general] Discussion period - Moving [community] to use same system as main repos

[stefan-husmann at t-online.de]

-----Original Message-----
> 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)"
> 

> Hi all,
> 
> 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 .
> 
> 
Hello,

I have been thinking about the detriments and benefits and  her are my
comments:

>Detriments
>* 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. 

Cannot comment

So in my opinion at now the benefits are small and the goals are not
mine. A clear -1 from me.

Regards Stefan