-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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
2014-08-17 17:25 GMT+02:00 mrlemux@gmail.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQEcBAEBAgAGBQJT8MlfAAoJEBWTDgtqAPQNRN4H/35h+X+KByf3rpgD19vPbbsq ipbR0njXcv/Uf+r9zCUdmWsWMaxyUDnc/cJLZLHQ852aYZa47GJmhVUK2sUcVVFj ySI4YDpssjEe1aooFigrx8gc87Z/AXFxpddZqBykAr6MmFPsICgBNnlwV9CiB3Hj Z1wBhO1AozgX6VMMSZnZ7Tx/n39lv9xe9xVk3GnsaGrHWwAcFDbbLDrOh6PvBHD8 KkJlsgJsEDmirfZuKhvEM+OQsId91zRNL4iRbjPAV78JfSkg04XRWD8JHWDOh+Vl J/WKiLPYoDJTgX9Uhh8Jl+gATvU+fDZnEzhfXU3msExKkDAhXlztOJkpgnF+fjA= =skx9 -----END PGP SIGNATURE-----
like this? http://pkgbuild.com/git/aur-mirror.git/tree/
On 2014-08-17 15:26, SpinFlo wrote:
2014-08-17 17:25 GMT+02:00 mrlemux@gmail.com:
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
2014-08-17 17:42 GMT+02:00 Doug Newgard scimmia@archlinux.info:
On 2014-08-17 15:26, SpinFlo wrote:
2014-08-17 17:25 GMT+02:00 mrlemux@gmail.com:
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
oh. thanks
On Sun, Aug 17, 2014 at 11:42 AM, Doug Newgard scimmia@archlinux.info wrote:
On 2014-08-17 15:26, SpinFlo wrote:
2014-08-17 17:25 GMT+02:00 mrlemux@gmail.com:
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, 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, ...
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.
[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 archlinux@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.
On 17/08, 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?
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.
On Sun, Aug 17, 2014 at 6:09 PM, Johannes Löthberg johannes@kyriasis.com wrote:
On 17/08, 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?
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 johannes@kyriasis.com wrote:
On 17/08, 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?
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
On 08/18/2014 12:57 AM, Lukas Fleischer wrote:
On Mon, 18 Aug 2014 at 00:21:41, Ido Rosen wrote:
On Sun, Aug 17, 2014 at 6:09 PM, Johannes Löthberg johannes@kyriasis.com wrote:
On 17/08, 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?
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?
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
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.
We could also have a development area(like this) for the AUR that isn't integrated into the main GUI(aur.archlinux.org) and replace the request button with a link to the devolepment area On 08/19/2014 12:15 AM, Massimiliano Torromeo wrote:
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.
On 19/08, Massimiliano Torromeo wrote:
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.
Unfortunately it's a pain to set up on Arch, and last time I tried I couldn't get it working.
On Tue, Aug 19, 2014 at 12:57 PM, Johannes Löthberg johannes@kyriasis.com wrote:
On 19/08, Massimiliano Torromeo wrote:
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.
Unfortunately it's a pain to set up on Arch, and last time I tried I couldn't get it working.
It's a pain to package on Arch (which is why I dropped the PKGBUILD I was maintaining on AUR) but if you just clone the repo in a folder and manage the dependencies with bundler (like suggested from upstream) it's fairly simple to do.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/19/2014 11:18 AM, carstene1ns wrote:
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:#<issue_number>}) 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:#<issue_number>}, or a designated close button
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.
aur-general@lists.archlinux.org