On Sun, 17 Aug 2014 at 23:56:25, Ido Rosen wrote:
On Sun, Aug 17, 2014 at 12:31 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote: [...]
* 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?
Huh? Why would you want to put them in different repositories? The point of having issue trackers per repository is that * bugs are automatically "assigned" to the right person, * bugs can be closed automatically when a fix is committed, * you can reference commits and files, * there is no need to filter by project (as in a global tracker). A separate tracker would be very hard to maintain. Tickets need to be assigned, permissions need to be kept in sync with the current repository owner, ...
[...] 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.
Note that the basic functionality is implemented already. In <500 lines of Python code, so this isn't too hard. One reason is that we do not have support for any of the fancy extra features right now (pull requests, forks, bug trackers, ...)
[...]
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.
I do not want to recommend any specific workflow. Git gives you a lot of flexibility when it comes to your workflow and I want to keep that flexibility. Of course, there will be basic instructions and tools for newcomers. If you want to use submodules, use submodules. The interface isn't different from the interface to any other Git repository. You can use `git clone`, `git pull`, `git push` and every official Git command to interact with remotes.