Just addressing a handful.
On Fri, Jan 9, 2009 at 2:04 PM, firstname.lastname@example.org email@example.com 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.
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.