[aur-general] AUR GIT and Bug Tracker

[Lukas Fleischer]

On Sun, 17 Aug 2014 at 23:56:25, Ido Rosen wrote:
> On Sun, Aug 17, 2014 at 12:31 PM, Lukas Fleischer
> <archlinux at 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.