On Sun, Aug 17, 2014 at 12:31 PM, Lukas Fleischer <[email protected]> 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.
