-----Original Message-----

Date: Fri, 09 Jan 2009 21:25:48 +0100 Subject: Re: [aur-general] Discussion period - Moving [community] to use same system as main repos From: "Aaron Griffin" To: "stefan-husmann@t-online.de" , "Discussion about the Arch User Repository (AUR)"

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.

Hello, I cannot speak of the technical merits of such a move. Technically spoken it may be useful. But I have strong issues against the goals with which this proposal is underlined and that many people seem to have in mind. Trusted Users are in first line Users and not small developers. I do not want [community] be closer to [extra], I want it as close to AUR as it is now. I want people to comment my packages without having to write a bug report.

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"

You are right regarding the proposal itself -- it is only about introducing a chain of tools replacing another chain of tools. But if that is the only thing that comes up here it would not even be worth a proposal. And if the devels decide to switch from cvs to svn the TUs would have to alter their tools anyway, regardless of any proposal. There are goals behind this first step. <* [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  detriment is in the first sentence of that paragraph. I think I explained my opinion about that. I have nothing against community packages showing up on www.archlinux.org directly. In fact this is already the case on www.archlinux.de. You can even see a complete filelist for each pakage in community there. So I think there is no need to switch to devtools just for that reason. Ask Pierre how he implemented it. Regards Stefan