On Sun, Dec 21, 2008 at 10:15 PM, Allan McRae email@example.com wrote:
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!
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!
- 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.
- 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.