Migrate AUR towards public subversion repository?

Question

The following idea has been in my head for some time; I was going to just build it; but I figured some discussion might be useful
I think the current setup of the AUR doesn't provide the tools for people to maintain a package. I frequently find myself wanting to add something without wanting to maintain it; or wanting to make a minor fix to an existing entry in the AUR. I know the first problem might be solved by disowning the package, but I have an alternative solution I would like your opinion on.
How about changing the AUR so it would be a web-interface to a subversion repository where everyone can change files in a wiki-like way? This would just be a light webinterface with a simple text-editor area, and some file management tools. The current user-database would be used to verify users, and there would be a single application-account in the svn repository. The application would maintain the relation between commits and users; thereby providing blame functionality to each file. The biggest difference would be that everyone could update every file; with the application providing a complete log of what was changed by who. For external applications to integrate with the AUR, the svn repository could be public read-only.
What do you think about this setup; feedback is welcome

Answer 1

rooloo wrote:I think there has to be some way of doing it like git, being able to have multiple branches of the same project. This way one could easily merge updates into the master private branch.
I was hoping that my suggestion of using subversion would not emerge into a cvs <> svn <> git discussion. What I mean is a versioned file repository and I couldn't care less about the actual implementation
dolby wrote:
I dont care what the AUR looks like or uses but i would prefer uploaded PKGBUILDs reviewed by TUs before uploaded & are accessible by users.
eg. http://slackbuilds.org/repository/12.1/graphics/scrot/
Yep, so would I. But what does that have to do with the idea I posted?
Allan wrote:
I guess the reason I like having a master PKGBUILD that only the maintainer can modify is so people can show their ability to create good PKGBUILDs and eventually become TUs.
Okay; but wouldn't that be just as visible by the changes they commit, as it would be by the number of packages they add?
Allan wrote:It also prevents abuse by malicious parties.
It does, but only a little bit since those parties could upload malicious PKGBUILDS just as well as they could edit existing ones. When locking of packages would be supported; it might defeat the whole idea of packages being publicly maintained.