[aur-general] AUR GIT and Bug Tracker

[Ido Rosen]

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