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

[Aaron Griffin]

Just addressing a handful.

On Fri, Jan 9, 2009 at 2:04 PM, stefan-husmann at t-online.de
<stefan-husmann at t-online.de> wrote:
>>*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.

I don't think this one is about "political consistency" - this
proposal is more about technical superiority. It's a technically
better move, so the proposal says "ok, screw the politics"


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

This is a very very BIG point. I remember back when pacman added in
new sizes, so that one could easilly see "total unpacked size" from
new packages. The community repo did not have these sizes added in, so
the numbers were treated as 0. You'd get things like:
   Total Download Size: 300MB
   Total Installed Size: 7MB
And people would yell and complain and file bug reports. This *only*
happened because we have different tools managing the community repo
as compared to the official repos (which stay up-to-date with regard
to pacman changes, as much as possible)

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

I think the point here was more about the actual _people_, not the
packages. If JoeSchmoe becomes a developer, he has no extra learning
to do and can begin work much easier.

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

Wait... can you explain how this is a detriment?

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

This is one of the most important points here. The backend managing
the community repo is, quite frankly, painful. It causes us way more
harm than the official repos ever had. Getting rid of this is the sole
reason I think this entire thing is work it.

I think we're mixing up a lot of issues here. Arch has always striven
for _technical_ superiority. Recently, we've had way too much talk of
politics and autonomy and all this other cruft and bureaucracy. The
simple fact is: this is a technically superior choice.

Just my 17 cents.