[aur-general] storming in for no reason with crazy ideas

[Aaron Griffin]

On Sun, Dec 21, 2008 at 10:15 PM, Allan McRae <allan at archlinux.org> wrote:
> eliott wrote:
>>
>> Hello!
>>
>> Long time reader, first time poster (in quite a while).
>> I was bored today, so I read through some of the mailing list archive.
>> Whew!
>>
>> Anyway, I had one of those crazy ideas that is, well, crazy. As this
>> is the internet and I have some free time, allow me to subject you all
>> to my crazy idea! Hooray!
>>
>> *coughs*
>>
>> Why not move towards separating the duties of the current AUR system
>> from the duties of the TU system. I propose making the TUs 'associate
>> arch devs', and having them use the main arch repository system, but
>> in a reduced security/permission role. Something like TUs getting
>> access to community only, like they have now..but using the same dev
>> tools system as the mainline devs, having community just be 'another
>> repo' in the main site interface (just like extra and core).
>>
>> Sure it will take a bit of effort, but it would streamline some
>> processes for sure!
>>
>> Detriments:
>>  - TUs wouldn't be as autonomous as they historically have been. This
>> could be good or bad, but putting it in the 'bad' category, because
>> people fear change..and this is a change.
>>  - It would take _some amount_ more than 0 value of effort to get the
>> TUs into the mainline dev system.
>>
>> Benefits:
>>  - Less tools to support, as the TUs would then use the same dev tools
>> as devs, but with limited permissions.
>>  - Process streamline
>>  - Clearer path for migration from 'associate dev' to 'dev'. Just flip
>> a bit in the permissions for the devtools, and they can now move
>> packages to extra or core, etc.
>>  - Decouple community from the AUR. The AUR would then 'be its own
>> bag'. Leaving end user voting as a guide for moving packages into
>> community (or not..whatever), then packages in community would
>> disappear from the aur when they were adopted into community.
>>  - Greater visibility for community repository. It is already included
>> by default, so it should be treated as such... a vital component to
>> the overall arch ecosystem.
>>  - Future AUR rewrites or refactoring would be greatly simplified.
>>  - The existing TU toolchain and server daemon can be jettisoned into
>> the abyss, to live with other lovecraftian horrors.
>>
>>
>> So there you have it.
>> Talk amongst yourselves.
>> I will be over here..hiding in the shrubbery.
>> o.O
>>
>
> I have been thinking about this for a while.  Another advantage is that
> [community] can easily have a [community-testing] repo or even just use
> [testing] directly.  And given we currently can given permissions for only
> using [extra] or [core], this would be fairly simple to do.

I've been thinking of this as well. It would require some design
effort from the server side though, but wouldn't be too hard. Do we
need full shell accounts for these users?

yes: Can be done in a minimal amount of time with very little changes
to the dbscripts. Management headache with regard to TUs vote new
people in periodically.

no: Would require a restricted sftp process, or some daemon for file
upload. Less management hassle, more code writing.

One of the good things here is that we could very easily allow some
TUs who have the gusto to commit to the main repo SVN (even
temporarily) to do changes like fixing licenses and the like. We can
give permissions to commit to the repos without permissions to upload
to the repos.

As I stated on the "backend rewrite" thread - I am raring to go and
anyone who wants to help out with the backend tools should contact me
offlist (things in my inbox take higher priority, usually).

Anyway, thanks for the mail cactus. It's always helpful to see ideas
thrown around. I've thought about this for some time, but feared the
TUs would be generally against it.