On 2014-08-17 15:26, SpinFlo wrote:

2014-08-17 17:25 GMT+02:00 :

...

Hi everyone,

i heard that something like a bug tracker/GIT for the packages in AUR is planned, and i've become curious how the state of it is

like this? http://pkgbuild.com/git/aur-mirror.git/tree/

No, he means like this: https://mailman.archlinux.org/pipermail/aur-dev/2014-June/002770.html https://mailman.archlinux.org/pipermail/aur-dev/2014-June/002789.html

On Sun, Aug 17, 2014 at 11:42 AM, Doug Newgard wrote:

On 2014-08-17 15:26, SpinFlo wrote:

...

2014-08-17 17:25 GMT+02:00 :

...

Hi everyone,

i heard that something like a bug tracker/GIT for the packages in AUR is planned, and i've become curious how the state of it is

like this? http://pkgbuild.com/git/aur-mirror.git/tree/

No, he means like this: https://mailman.archlinux.org/pipermail/aur-dev/2014-June/002770.html https://mailman.archlinux.org/pipermail/aur-dev/2014-June/002789.html

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. [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.

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

On Sun, Aug 17, 2014 at 6:09 PM, Johannes Löthberg wrote:

On 17/08, Ido Rosen wrote:

...

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

Because then we'd either need two repos per package or one repo that had the bug reports of all the AUR packages, both would be rather bad solutions.

Why would comments and bugs need to be managed in Git to begin with? GitHub and other services do sometimes have a handy issues.git repository (e.g. I can clone http://github.com/ido/packages-archlinux.issues.git ), but I don't think the backing store is Git in those cases...? Having a Git interface to that data is handy but does imply having a separate "git repo". Using Git as a backing store for comments/bugs might be inelegant/not very KISS. Also, to delete a comment in the comment history if it's maintained in Git would you resort to a non-fast-forward update? Don't interpret my questions as discouragement, just seems like using Git for *everything* is a bit myopic.

-- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5

On Mon, 18 Aug 2014 at 00:21:41, Ido Rosen wrote:

On Sun, Aug 17, 2014 at 6:09 PM, Johannes Löthberg wrote:

...

On 17/08, Ido Rosen wrote:

...

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

Because then we'd either need two repos per package or one repo that had the bug reports of all the AUR packages, both would be rather bad solutions.

Why would comments and bugs need to be managed in Git to begin with? GitHub and other services do sometimes have a handy issues.git repository (e.g. I can clone http://github.com/ido/packages-archlinux.issues.git ), but I don't think the backing store is Git in those cases...? Having a Git interface to that data is handy but does imply having a separate "git repo". Using Git as a backing store for comments/bugs might be inelegant/not very KISS. Also, to delete a comment in the comment history if it's maintained in Git would you resort to a non-fast-forward update?

Don't interpret my questions as discouragement, just seems like using Git for *everything* is a bit myopic.

I never suggested to manage comments or bugs in Git. However, when using a service like GitHub, repositories and tickets are coupled together. If we do not want to make use of GitHub's issue tracker (and pull requests and all the other features) we do not gain anything. You suggested to search for an existing service in order to not reinvent the wheel. What is the point of using such a service if we do not use the wheel at all?

...

-- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5

At work I did setup gitlab community edition [1] on our servers to self-host all our projects and it has many similarities with github. It has been working fine for quite some time (migrated from a self-hosted gitorious) and could be a possible solution if we want to host the repositories on our servers and eventually develop custom integrations. [1] https://about.gitlab.com/gitlab-ce/

Am 18.08.2014 um 10:01 schrieb mrlemux@gmail.com:

the problem is that most issue tracking systems are too heavy for our uses(correct me if i'm wrong), and if we want it really KISS we have to implent an issue tracking system ourselves (with a feature base like github's one). i think it could replace the current comment section as it is mostly used for reporting Bugs already

I also like this idea. Over the years the package pages have been cluttered with comments that are not applicable today anymore. Who cares today, if a version from 2007 did not compile correctly? Also users tend to write a small comment "version x.y is out" when flagging a package out of date and leave it there after the package has been updated. It would be nice to have a lightweight tracker, that allows the user to choose between at least 3 types of ticket: bug, comment, out-of-date. The maintainer can then close an out-of-date ticket with a git push or respond to a bug report. Comments that are not not relevant anymore can also be closed after a time. If we think this a bit further, also the request system can be integrated as tickets that can be only closed by a TU. This would also avoid the cluttering we have today with the additional mailing list, as closed tickets can be shown when needed later. best regards, carstene1ns

Am 18.08.2014 um 10:01 schrieb mrlemux@gmail.com:

...

the problem is that most issue tracking systems are too heavy for our uses(correct me if i'm wrong), and if we want it really KISS we have to implent an issue tracking system ourselves (with a feature base like github's one). i think it could replace the current comment section as it is mostly used for reporting Bugs already

I also like this idea. Over the years the package pages have been cluttered with comments that are not applicable today anymore. Who cares today, if a version from 2007 did not compile correctly? Also users tend to write a small comment "version x.y is out" when flagging a package out of date and leave it there after the package has been updated. It would be nice to have a lightweight tracker, that allows the user to choose between at least 3 types of ticket: bug, comment, out-of-date. The maintainer can then close an out-of-date ticket with a git push or respond to a bug report. Comments that are not not relevant anymore can also be closed after a time. If we think this a bit further, also the request system can be integrated as tickets that can be only closed by a TU. This would also avoid the cluttering we have today with the additional mailing list, as closed tickets can be shown when needed later. I think everything should be a "bug",and TU's and maintainers should both have the same rights(the right to merge commits(But there are rules they have to follow)), users could associate commits by commiting there files with a special tag that referes to that "bug"(something like {fix:#})

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/19/2014 11:18 AM, carstene1ns wrote: these would then also appear in the current "thread" The bug could then, be either closed by merging the commit with the assoxiated {fix:#} (Users have 5 Days time to reopen the bug if it just fixes half of it or something like that) or have a specialcommit which refers to the bug in the commit message(something like {close:#}, or a designated close button -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT8y+gAAoJEBWTDgtqAPQNwakIAL1LqjjG9olQTIxYenygbqlL x8Ww2nHxz4dnYo3eE5QAJDwSqJ96fUJHltqZ+OLZ6tjM2KPsqGJ0bw7Fla9n5Dgo 9hdgg6YDIZAQJ8IesDRCiE6HQBf2plJ7BMqqA8pJCRYW7KGYc22JTkMs6kQryuWG 95HreC1keixXMbew4Udb3ECDquCUsCKEzw5Q6dHlgQPVlVRMZ4XqrJ92n3eOlII+ EBlriPSAWtYgAyb9R6MrLycsuLOT0A+gOE5CaU5UbVaDPiVL2ev9qsKARJ1uypTA iT2lQNZkRSrQ8C63VRx+8lN4zUI7SFZfOktoawh2sE2F6wkzgdCt5JeLJs+WruA= =1geE -----END PGP SIGNATURE-----