On Tue 14 Dec 2010 09:54 -0200, Tomás Acauan Schertel wrote: > The Brazilian Arch Linux Community wants to help Arch Linux project, > working on bug reports and feature requests. > As first task, we plan to help conclude the development of AUR version 2. > > We don't have lots of developers, but we really want to help. And > maybe others join us on this effort. > > To accomplish this, we need to enlighten some points: > > 1 - where should we look for feature requests? > * bugs.archlinux.org? > * AUR2 wiki page? > > 2 - what code repository should we take as start point? > * git://gitorious.org/aur2/aur2.git -- the "central" repository with > the stable branch > * git://github.com/sebnow/aur2.git -- Xilon's repository > * git://ius.student.utwente.nl/aur2 -- Thralas's repository > * git://git.berlios.de/aur2 -- Djszapi's repository > * git://github.com/SpeedVin/aur2.git -- SpeedVin's AUR2 forked repo > with some patches and translation's. > > 3 - How Feature Requests / Bug Reports will be closed on flyspray? > * Maybe a TU can do the job. > > Maybe things get easier if just one (maybe two) TU`s leads us on work. Well, the AUR2 is a completely independent project. I don't think that it should be tracked on the bugtracker for the current AUR - that's unless the Trusted Users decide to adopt it instead of the current codebase. So the answer to question 1 would be the wiki page. 2. I believe you should follow the "central" repo if you decide to develop on AUR2. 3. I think it's best if AUR2 had a separate tracker. Finally, I'd like to honestly say I don't see AUR2 as really being a worthwhile investment for the next generation of the AUR. It's just another web app like the current AUR, it might have a couple extra frills, but I don't think it makes sense to rewrite the whole thing just for that sake. They can probably added easily enough to the current code. As I see it I agree totally with Anthony's vision of what the future of the AUR should look like. I've actually thought about this for a few years, but I lack the talent to start any implementation. I'm not sure if we will be able to jump right into it though. It might take a couple of generations of the system. A first step would be to take the interface out of the server and have the client deal with that. I think you should take a look at Eli Janssen's AUR json daemon. https://github.com/cactus/spew and C Anthony Risinger's aur-pyjs https://github.com/extofme/aur-pyjs Cheers.
