[aur-general] AUR activity log?
Hi, In light of the mass deletion of many orphaned as well as not-really-orphaned packages, it would be nice if there were a way to get a log of AUR activity so that users other than just a package's maintainers can see that a package disappeared at some given point. It was also mentioned that deleted packages aren't really deleted, merely hidden--in that case, why not allow users to view these packages if some flag is set in the API request? This way, users can pick up maintenance of a once-extant package without having to recreate it from scratch. Thanks, Mark Laws -- |v\ /\ |\ |< |_ /\ \^| //
Em 12-08-2015 11:54, Mark Laws escreveu:
In light of the mass deletion of many orphaned as well as not-really-orphaned packages
They were really orphaned. And it was warned that orphaned packages would be "deleted" on Aug 8th.
, it would be nice if there were a way to get a log of AUR activity so that users other than just a package's maintainers can see that a package disappeared at some given point.
A maintainer in this scenario wouldn't be anything more than a user? He/She disowned the package didn't?
It was also mentioned that deleted packages aren't really deleted, merely hidden--in that case, why not allow users to view these packages if some flag is set in the API request? This way, users can pick up maintenance of a once-extant package without having to recreate it from scratch.
I think that even if a package isn't showing in the AUR interface anymore, you can clone it's repo, if you at least remember/know the name of the package. Since the packages aren't deleted and just "hidden", I think you'd get not an empty repo, but the repo as it was in the moment of the "deletion". But this, of course, for packages that were migrated to the new AUR, and then orphaned. For packages not migrated, I don't think there is a repo there. Cheers, Giancarlo Razzolini
On Wed, Aug 12, 2015 at 5:09 PM, Giancarlo Razzolini <grazzolini@gmail.com> wrote:
For packages not migrated, I don't think there is a repo there.
https://wiki.archlinux.org/index.php/Arch_User_Repository#Git_repository ?
On Thu, Aug 13, 2015 at 12:20 AM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
https://wiki.archlinux.org/index.php/Arch_User_Repository#Git_repository ?
I was wondering if there was something like this. Thanks! Cheers, Mark Laws -- |v\ /\ |\ |< |_ /\ \^| //
Wed, 12 Aug 2015 12:09:51 -0300 Giancarlo Razzolini <grazzolini@gmail.com>:
They were really orphaned. And it was warned that orphaned packages would be "deleted" on Aug 8th.
<nitpick> The announced (and executed) deletion was about stale AUR3 metadata (migrated packages that weren't 'git push'ed) in the AUR4 database, no objections there. Our main issue here is about orphaned PKGBUILDs that got manually deleted after the transition was over. </nitpick> --byte
Em 12-08-2015 12:42, Jens Adam escreveu:
Our main issue here is about orphaned PKGBUILDs that got manually deleted after the transition was over.
But these were migrated to and then orphaned on the new AUR right? I don't think that it was wrong to "hide" these when the subdomain migrated on Aug 8th. Again, I believe that if you clone the git repository, even if the package is "hidden", you will get the PKGBUILD and other contents that were there, not an empty repo. I might be wrong, but looking at the aur source code, I don't see anything preventing this. So, the packages that weren't migrated are on the aur-mirror. The packages that were, and then were "hidden", are still there. Try and see. Cheers, Giancarlo Razzolini
Wed, 12 Aug 2015 13:54:31 -0300 Giancarlo Razzolini <grazzolini@gmail.com>:
I don't think that it was wrong to "hide" these when the subdomain migrated on Aug 8th.
That wasn't what happened. Read the thread(s) again - a single TU went around and deleted a bunch of freshly orphaned packages, nothing to do with the migration. --byte
Em 12-08-2015 14:10, Jens Adam escreveu:
That wasn't what happened. Read the thread(s) again - a single TU went around and deleted a bunch of freshly orphaned packages, nothing to do with the migration.
I really don't see the issue here, even if is this that happened. They were orphaned, weren't they? And, they aren't deleted, they are "hidden". Unless the TU also removed the git repository, which I believe didn't happened. Truth is, the disown functionality has been misused and you can't really complain if you orphaned a package and it was deleted. Even more now that AUR has a co-maintainer functionality. Cheers, Giancarlo Razzolini
On Thu, 13 Aug 2015 at 03:17 Giancarlo Razzolini <grazzolini@gmail.com> wrote:
Em 12-08-2015 14:10, Jens Adam escreveu:
That wasn't what happened. Read the thread(s) again - a single TU went around and deleted a bunch of freshly orphaned packages, nothing to do with the migration.
I really don't see the issue here, even if is this that happened. They were orphaned, weren't they? And, they aren't deleted, they are "hidden". Unless the TU also removed the git repository, which I believe didn't happened. Truth is, the disown functionality has been misused and you can't really complain if you orphaned a package and it was deleted. Even more now that AUR has a co-maintainer functionality.
Cheers, Giancarlo Razzolini
But by 'hidden' it also deletes all comments and votes, and stops people being able to search for the package, see that it isn't maintained and picking it up. Almost all of my packages have become mine by trying to install something, finding it useful, and when it became an orphan, just taking it over and fixing it up. If we wanted to delete packages we would have asked for deletion, not orphaned it. What is the point of orphaning packages if they are just going to get deleted anyway? - Justin
Em 12-08-2015 14:21, Justin Dray escreveu:
But by 'hidden' it also deletes all comments and votes, and stops people being able to search for the package, see that it isn't maintained and picking it up.
Well, the TU could have waited, I give you that.
Almost all of my packages have become mine by trying to install something, finding it useful, and when it became an orphan, just taking it over and fixing it up.
This is how I ended up maintaining quite a few packages. But I didn't waited for them to become orphan, in most cases.
If we wanted to delete packages we would have asked for deletion, not orphaned it. What is the point of orphaning packages if they are just going to get deleted anyway?
Now this is were I fail to see the point. If you still wanted/needed the package, why orphan it? I'm perfectly happy with the way AUR works today. But, if you guys really want orphaned packages to stay around for some time, I suggest you guys implement it and send a diff. Perhaps something that prevents even a TU from deleting (hiding) a orphaned package that isn't orphan long enough, lets say, a couple of months. Cheers, Giancarlo Razzolini
On Thu, 13 Aug 2015 03:36 Giancarlo Razzolini <grazzolini@gmail.com> wrote: Em 12-08-2015 14:21, Justin Dray escreveu:
But by 'hidden' it also deletes all comments and votes, and stops people being able to search for the package, see that it isn't maintained and picking it up.
Well, the TU could have waited, I give you that.
Almost all of my packages have become mine by trying to install something, finding it useful, and when it became an orphan, just taking it over and fixing it up.
This is how I ended up maintaining quite a few packages. But I didn't waited for them to become orphan, in most cases.
If we wanted to delete packages we would have asked for deletion, not orphaned it. What is the point of orphaning packages if they are just going to get deleted anyway?
Now this is were I fail to see the point. If you still wanted/needed the package, why orphan it? I'm perfectly happy with the way AUR works today. But, if you guys really want orphaned packages to stay around for some time, I suggest you guys implement it and send a diff. Perhaps something that prevents even a TU from deleting (hiding) a orphaned package that isn't orphan long enough, lets say, a couple of months. Cheers, Giancarlo Razzolini Perhaps seeing active comments or that the packages had to have been updated within month since everything was cleared for AUR4? We already have a mechanism for disowning a package and allowing others to maintain it without deleting it. It's called orphaning. The problem here is that how they are treated has apparently changed with no community involvement or even a warning that orphan packages will be deleted at random. Perhaps if TUs are able to view the last updated time from a search fable, they could see an orphaned package with no updates for X months. But as has been said before, orphaned does not mean useless or broken. - Justin
Em 12-08-2015 14:42, Justin Dray escreveu:
Perhaps seeing active comments or that the packages had to have been updated within month since everything was cleared for AUR4?
Comments aren't the best way. A package can work so well as to not have any comments for a long time. Or is simple enough that won't need comments. Or has a nice wiki page. The best way is, if a package is orphaned for some time, doesn't have actual PKGBUILD downloads for some time, it is a perfect candidate for deletion.
We already have a mechanism for disowning a package and allowing others to maintain it without deleting it. It's called orphaning.
This is not the mechanism for that, and it is the reason why the co-maintainer functionality was created. Using disown for this is wrong.
The problem here is that how they are treated has apparently changed with no community involvement or even a warning that orphan packages will be deleted at random.
I don't think it was a policy change nor anything.
Perhaps if TUs are able to view the last updated time from a search fable, they could see an orphaned package with no updates for X months. But as has been said before, orphaned does not mean useless or broken.
Oprhan packages can't be updated, right? And, even if it wasn't update for years before it was disowned, doesn't meant it was not useful anymore. The metric here should be based on relevance (actual PKGBUILD downloads) and time since it become orphan. Cheers, Giancarlo Razzolini
On Wed, 12 Aug 2015 14:54:56 -0300 Giancarlo Razzolini <grazzolini@gmail.com> wrote:
We already have a mechanism for disowning a package and allowing others to maintain it without deleting it. It's called orphaning.
This is not the mechanism for that, and it is the reason why the co-maintainer functionality was created. Using disown for this is wrong.
On the contrary, this is exactly the mechanism for that. You disown a package so that someone else can adopt it. Why else would you disown a package?
Perhaps if TUs are able to view the last updated time from a search fable, they could see an orphaned package with no updates for X months. But as has been said before, orphaned does not mean useless or broken.
Oprhan packages can't be updated, right?
Sure they can, why wouldn't they be? Doug
Em 12-08-2015 15:01, Doug Newgard escreveu:
On the contrary, this is exactly the mechanism for that. You disown a package so that someone else can adopt it. Why else would you disown a package?
Let me rephrase it. Disowning a package isn't the mechanism for allowing others to maintain a package, if you still need/use/care for it. Co-maintainer functionality is for that. There were people on the old AUR that would disown a package so that someone else could update it, and then disown it again, and so on. This should end.
Sure they can, why wouldn't they be?
If someone adopt it. When they are in orphaned status, they can't. But, then again, if someone adopt it, then it wouldn't be deleted, and we wouldn't be having this discussion. Cheers, Giancarlo Razzolini
On Wed, 12 Aug 2015 15:07:57 -0300 Giancarlo Razzolini <grazzolini@gmail.com> wrote:
Em 12-08-2015 15:01, Doug Newgard escreveu:
On the contrary, this is exactly the mechanism for that. You disown a package so that someone else can adopt it. Why else would you disown a package?
Let me rephrase it. Disowning a package isn't the mechanism for allowing others to maintain a package, if you still need/use/care for it. Co-maintainer functionality is for that. There were people on the old AUR that would disown a package so that someone else could update it, and then disown it again, and so on. This should end.
You aren't getting it. If you don't want to maintain a package and want to make it available to others, you disown it. This doesn't mean you want it deleted, it simply means you want someone else to maintain it. If someone approaches you and want to help, you make them a co-maintainer. Two completely different things.
Sure they can, why wouldn't they be?
If someone adopt it. When they are in orphaned status, they can't. But, then again, if someone adopt it, then it wouldn't be deleted, and we wouldn't be having this discussion.
Anyone can push to the repo of an orphaned package. That person then automatically becomes the maintainer, but will often simply disown it again. Doug
On Thu, 13 Aug 2015 at 04:20 Doug Newgard <scimmia@archlinux.info> wrote:
On Wed, 12 Aug 2015 15:07:57 -0300 Giancarlo Razzolini <grazzolini@gmail.com> wrote:
On the contrary, this is exactly the mechanism for that. You disown a
Em 12-08-2015 15:01, Doug Newgard escreveu: package
so that someone else can adopt it. Why else would you disown a package?
Let me rephrase it. Disowning a package isn't the mechanism for allowing others to maintain a package, if you still need/use/care for it. Co-maintainer functionality is for that. There were people on the old AUR that would disown a package so that someone else could update it, and then disown it again, and so on. This should end.
You aren't getting it. If you don't want to maintain a package and want to make it available to others, you disown it. This doesn't mean you want it deleted, it simply means you want someone else to maintain it. If someone approaches you and want to help, you make them a co-maintainer. Two completely different things.
Sure they can, why wouldn't they be?
If someone adopt it. When they are in orphaned status, they can't. But, then again, if someone adopt it, then it wouldn't be deleted, and we wouldn't be having this discussion.
Anyone can push to the repo of an orphaned package. That person then automatically becomes the maintainer, but will often simply disown it again.
Doug
There's definitely some discrepancies in how we're all thinking about how it should work (for the record I'm totally aligned with Doug in this regard), but I have to say:
The metric here should be based on relevance (actual PKGBUILD downloads) and time since it become orphan.
Sounds perfect. But we currently don't have a way (or not that I'm aware of anyway) to do this without opening each package manually. Having even a weekly/monthly script run through that data and present a list of old/possible unused orphans would be pretty helpful. - Justin
On Wed, 12 Aug 2015 14:17:12 -0300 Giancarlo Razzolini <grazzolini@gmail.com> wrote:
Em 12-08-2015 14:10, Jens Adam escreveu:
That wasn't what happened. Read the thread(s) again - a single TU went around and deleted a bunch of freshly orphaned packages, nothing to do with the migration.
I really don't see the issue here, even if is this that happened. They were orphaned, weren't they? And, they aren't deleted, they are "hidden". Unless the TU also removed the git repository, which I believe didn't happened. Truth is, the disown functionality has been misused and you can't really complain if you orphaned a package and it was deleted. Even more now that AUR has a co-maintainer functionality.
Cheers, Giancarlo Razzolini
Just because they were orphaned doesn't mean they weren't useful. You don't see anything wrong with deleting a package a couple of hours after a maintainer orphans it? They were deleted in the sense that they are no longer generally available, and all comments, notifications, and votes are gone for good. Doug
On 12.08.15 at 23:54, Mark Laws wrote:
Hi,
In light of the mass deletion of many orphaned as well as not-really-orphaned packages, it would be nice if there were a way to get a log of AUR activity so that users other than just a package's maintainers can see that a package disappeared at some given point.
It was also mentioned that deleted packages aren't really deleted, merely hidden--in that case, why not allow users to view these packages if some flag is set in the API request? This way, users can pick up maintenance of a once-extant package without having to recreate it from scratch.
Thanks, Mark Laws
-- |v\ /\ |\ |< |_ /\ \^| //
Let me add that this would be great for the maintenance of links to the AUR packages from the wiki -- when broken links are automatically marked with a {{Broken package link}} template by a bot, it would be possible to provide something better than "package not found" as a hint. For example differentiating between merging and deletions of packages would be a notable improvement. -- jlk
participants (7)
-
Doug Newgard
-
Giancarlo Razzolini
-
Jakub Klinkovský
-
Jens Adam
-
Justin Dray
-
Karol Blazewicz
-
Mark Laws