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

[Ghost1227]

Allan McRae 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.
>
> Allan
>
>
>
>
+1 Great idea! (one of those why didn't that ever occur to me things)... 
My only question is, Allan, if you've been thinking of this for a while, 
why are you hesitating to implement it? And what can we as TUs do to 
help see this come to fruition/make the transition easier?

-- 
Your Fortune...
---------------
"BYTE editors are men who seperate the wheat from the chaff, and then
 print the chaff."
-- Lionel Hummel (uiucdcs!hummel), derived from a quote by Adlai Stevenson, Sr.