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.