[arch-general] We want to help

[Loui Chang]

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.