[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 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 at 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