On Sun, Aug 17, 2014 at 12:31 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
On Sun, 17 Aug 2014 at 17:50:54, Ido Rosen wrote:
[...] Seeing the discussion about using info/alternates to store git objects for all repos in one place, it sounds a lot like they're reinventing the wheel... Git integration would be fantastic, but I'd strongly suggest that AUR devs not reinvent the wheel - let GitHub or BitBucket or Gitorious, etc. do the Git hosting for you, and do actions based on web-hooks[1], which most git hosts support.
It is not only about parsing package data. We need a centralized place where people can submit and discuss packages. That centralized place must allow for easily changing the maintainer (disown/adopt) and we (the Trusted Users) need full control (permissions to delete, merge, remove comments, ...) of every repository.
A first idea was to using existing services for hosting but then there are only two options:
* Statically connect each AUR package to a repository that is hosted somewhere else. Means we do not have full control over the repositories since we do not host them and we cannot simply switch to another repository if the maintainer becomes inactive/irresponsible.
* Dynamically connect each AUR package to a repository, so that it is easy to switch to a new repository if someone maintains a fork of the same package somewhere. Means we are going to lose all comments, bug tickets, ...
Why would you lose all comments/bugs/tickets? Why do those have to be in the same repository as the packages themselves?
So we cannot use any features the Git hosting services provide, apart from hosting the repositories themselves which is trivial (apart from authentication stuff that has already been implemented, though). As a byproduct of setting up our own SSH/Git infrastructure, you will also be able to perform several basic AUR operations (create a new package, adopt a package, ...) via the command line which is a nice feature on its own.
You can still collaborate using a decentralized work flow, put your stuff on GitHub, let people issue pull requests etc. but the main repositories will be hosted on aur.archlinux.org.
I don't personally mind if I end up using GitHub or some other Git hosting like AUR's homegrown solution - the interface is the same to me for the most part. I was just suggesting that you use existing ones because you will probably encounter the same issues existing ones have on the backend and it may be a waste of resources to create yet another git hosting service...even a special-purpose one. I hope whichever way you go succeeds. I agree that it's a good approach overall to store the PKGBUILDs and associated files in a version controlled repository rather than ephemeral tarballs.
[1] https://developer.github.com/webhooks/
PS: I already maintain all of my PKGBUILDs in one git repository on GitHub (https://github.com/ido/packages-archlinux). If the git integration supports GitHub (or even if not), I would then switch to adding each of the packages as git submodules to my master project (which would include a vagrantfile and my build environment)...making my package build environment reproducible for any other packagers/AUR users.
Think about workflows when designing this thing. I hope there is documentation centered around packaging workflows when you release the new features, the use case I'm especially interested in is to be able to submodule/subtree whatever packages I want from AUR into a new ArchLinux-based sub-distro and build them all... Also, it'd be very nice if the interface were the same for ABS/packages.git as it were for AUR, for example, you could consider ABS a subset of AUR... This line of discussion is probably worth a separate thread, and I'm not sure which the best mailing list to discuss it would be.