[aur-general] Deletion of orphaned packages on AUR4

newer
[aur-general] My Packages...

older
[aur-general] Signoff report for...

Rob McCathie

11 Aug 2015 11 Aug '15

6:40 a.m.

On Mon, Aug 10, 2015 at 8:30 AM, wrote:

...

Kyrias deleted "compiz-gtk-standalone".

You will no longer receive notifications about this package.

On Mon, Aug 10, 2015 at 8:32 AM, wrote:

...

Kyrias deleted "compiz-xfce".

You will no longer receive notifications about this package.

Just a query: Why were packages i added to AUR4, ensured were in good working order (and made an enhancement to one of the packages compared to the last release on AUR3), know are used by at least some users, and then orphaned so some other interested party can take over maintenance, were deleted from AUR4? compiz-gtk-standalone was actually the ONLY package on AUR4 that provided the Compiz 0.8 series core component. Since it's deletion there is now at least one package on AUR4 that has unresolvable dependencies. (eg. https://aur.archlinux.org/packages/ccsm/ ) Regards, Rob McCathie

Show replies by date

Antonio Rojas

11 Aug 11 Aug

7:09 a.m.

Rob McCathie Wrote in message:

...

Just a query: Why were packages i added to AUR4, ensured were in good working order (and made an enhancement to one of the packages compared to the last release on AUR3), know are used by at least some users, and then orphaned so some other interested party can take over maintenance, were deleted from AUR4?

compiz-gtk-standalone was actually the ONLY package on AUR4 that provided the Compiz 0.8 series core component. Since it's deletion there is now at least one package on AUR4 that has unresolvable dependencies. (eg. https://aur.archlinux.org/packages/ccsm/ )

Regards, Rob McCathie

I was wondering the same thing... Many of the kde-applications git packages that I uploaded to AUR4 and then disowned ( but were working fine) have been deleted, and I can't find any related request. --

Justin Dray

7:36 a.m.

On Tue, 11 Aug 2015 17:09 Antonio Rojas wrote:

...

Rob McCathie Wrote in message:

...
Just a query: Why were packages i added to AUR4, ensured were in good working order (and made an enhancement to one of the packages compared to the last release on AUR3), know are used by at least some users, and then orphaned so some other interested party can take over maintenance, were deleted from AUR4?

compiz-gtk-standalone was actually the ONLY package on AUR4 that provided the Compiz 0.8 series core component. Since it's deletion there is now at least one package on AUR4 that has unresolvable dependencies. (eg. https://aur.archlinux.org/packages/ccsm/ )

Regards, Rob McCathie

I was wondering the same thing... Many of the kde-applications git packages that I uploaded to AUR4 and then disowned ( but were working fine) have been deleted, and I can't find any related request. --

I also disowned an LSI raid card utility a few days ago, and it got deleted within 2 hours. What's going on with this? - Justin

David Phillips

8:15 a.m.

A certain TU went around deleting orphaned stuff… won't name them though ;-)

Bruno Pagani

12:30 p.m.

Well, the first email states Kyrias did this… Le 11 août 2015 10:15:42 GMT+02:00, David Phillips a écrit :

...

A certain TU went around deleting orphaned stuff… won't name them though ;-)

David Kaylor

1:12 p.m.

On Tue, Aug 11, 2015 at 8:30 AM, Bruno Pagani wrote:

...

Well, the first email states Kyrias did this…

Le 11 août 2015 10:15:42 GMT+02:00, David Phillips a écrit :

...
A certain TU went around deleting orphaned stuff… won't name them though ;-)

Don't know what the motivation is behind this particular TU (or any others) prowling around looking for orphans to delete, but there are two key issues, I think: - First, the move to aurweb4 was technically about maintainability and modernization of the AUR. But a big side benefit was the "thinning of the herd" (my words alone) that would take place, in terms of lackluster maintainership. A key TU behind the AUR4 redesign admitted as much in an earlier reply to me, @ 2 months ago. He disapproved of the "thinning of the herd" analogy for some reason, but that was clearly what he meant. There were to many orphans, and to many no-show maintainers. Probably still are. - Second, uploading something to AUR4 then immediately orphaning it is stupid. Why not just hold onto it for a while and look for co-maintainers, or a new maintainer? By orphaning, you just became the "thinned" part of the herd.

Sam S.

4:54 p.m.

...

Second, uploading something to AUR4 then immediately orphaning it is stupid. Why not just hold onto it for a while and look for co-maintainers, or a new maintainer? By orphaning, you just became the "thinned" part of the herd.

Well, if it's orphaned another potential maintainer who comes across it, might be more likely to pick it up. If it's *not* orphaned, they'd have to contact you first to ask you to transfer ownership or add them as co-maintainer - and even though that's not a *big* social cost, it is one nonetheless, and some potential maintainers will just not bother. I.e. it's a matter of making things run more smoothly/conveniently. IMO orphaned packages should *only* be deleted after an ample grace period (for example, when they've been orphaned for at least 4 months or so).

David Phillips

9:23 p.m.

I suppose some may subscribe to the view that if someone wants it badly enough, they'll submit, maintain and stick with it.

Justin Dray

12 Aug 12 Aug

12:42 a.m.

On Wed, 12 Aug 2015 07:24 David Phillips wrote:

...

I suppose some may subscribe to the view that if someone wants it badly enough, they'll submit, maintain and stick with it.

In my case, I uploaded a perfectly working package for LSI raid controllers, but someone commented that a newer version was available, I no longer use any LSI controllers and can't test that it is working correctly with the new version, I said as such, and orphaned the package only for it to be deleted within a couple hours. If orphaned packages are going to be deleted straight away I would have hung on to it. But then what is the point of their being an orphan button? There's already a delete one. It's seems really poor form to be just deleting any random orphaned packages off the AUR. Perhaps TUs that are doing this should no longer be TUs since they are clearly abusing that privilege to do things however they want instead of within the guidelines set by the community. - Justin

David Kaylor

3:32 a.m.

On Tue, Aug 11, 2015 at 5:23 PM, David Phillips wrote:

...

I suppose some may subscribe to the view that if someone wants it badly enough, they'll submit, maintain and stick with it.

Exactly.

Antonio Rojas

11 Aug 11 Aug

9:23 p.m.

David Kaylor Wrote in message:

...

- Second, uploading something to AUR4 then immediately orphaning it is stupid. Why not just hold onto it for a while and look for co-maintainers, or a new maintainer? By orphaning, you just became the "thinned" part of the herd.

Just because you can't think of a reason doesn't mean it's "stupid". TUs and developers may drop packages from the repos to AUR and then orphan them for someone to adopt. Someone may upload a package as a dependency of another package they maintain, which they're not interested in maintaining. Just to name a few possible reasons. --

Simon Hanna

12:08 p.m.

...

On Tue, 11 Aug 2015 17:09 Antonio Rojas wrote:

...
Rob McCathie Wrote in message:

...
Just a query: Why were packages i added to AUR4, ensured were in good working order (and made an enhancement to one of the packages compared to the last release on AUR3), know are used by at least some users, and then orphaned so some other interested party can take over maintenance, were deleted from AUR4?

compiz-gtk-standalone was actually the ONLY package on AUR4 that provided the Compiz 0.8 series core component. Since it's deletion there is now at least one package on AUR4 that has unresolvable dependencies. (eg. https://aur.archlinux.org/packages/ccsm/ )

Regards, Rob McCathie

I was wondering the same thing... Many of the kde-applications git packages that I uploaded to AUR4 and then disowned ( but were working fine) have been deleted, and I can't find any related request. --

I also disowned an LSI raid card utility a few days ago, and it got deleted within 2 hours. What's going on with this?

- Justin I guess you should either be responsible for a package or not upload one at all. AUR3 was full of really bad orphaned packages. In AUR4 you can add co-maintainers or even publish your repos to some service as github and accept

On Tue, Aug 11, 2015 at 07:36:53AM +0000, Justin Dray wrote: pull requests. I personally don't see any reason behind uploading a package and then immediately disowning it.

Johannes Dewender

1:48 p.m.

Am 11.08.2015 um 14:08 schrieb Simon Hanna:

...

On Tue, Aug 11, 2015 at 07:36:53AM +0000, Justin Dray wrote:

...
On Tue, 11 Aug 2015 17:09 Antonio Rojas wrote:

...
Rob McCathie Wrote in message:

...
Just a query: Why were packages i added to AUR4, ensured were in good working order (and made an enhancement to one of the packages compared to the last release on AUR3), know are used by at least some users, and then orphaned so some other interested party can take over maintenance, were deleted from AUR4?

compiz-gtk-standalone was actually the ONLY package on AUR4 that provided the Compiz 0.8 series core component. Since it's deletion there is now at least one package on AUR4 that has unresolvable dependencies. (eg. https://aur.archlinux.org/packages/ccsm/ )

I was wondering the same thing... Many of the kde-applications git packages that I uploaded to AUR4 and then disowned ( but were working fine) have been deleted, and I can't find any related request.

I also disowned an LSI raid card utility a few days ago, and it got deleted within 2 hours. What's going on with this?

I guess you should either be responsible for a package or not upload one at all. AUR3 was full of really bad orphaned packages. In AUR4 you can add co-maintainers or even publish your repos to some service as github and accept pull requests. I personally don't see any reason behind uploading a package and then immediately disowning it.

Well, to give an example on my end: The LIO target (for iSCI and such) For most of the LIO related packages there are original packages that are open source, but with no good community management (got better though). Then there are "free branch" forks as community projects. I uploaded both to AUR3 and also to AUR4. I maintain the free branch, because I think this is the better variant. Having the original on AUR would be good, so I also updloaded these, but I personally don't want to maintain these. There are however some users that still want to use the original. There aren't many changes either, since the original doesn't have releases often. (the free branch has lots of releases) the "free branch": https://aur.archlinux.org/packages/targetcli-fb/ https://aur.archlinux.org/pkgbase/python-rtslib-fb/ The "original" included: lio-utils/lio-snmp python2-rtslib targetcli (all deleted from AUR recently, lio-utils had more votes than any of the free branch packages) related wiki: https://wiki.archlinux.org/index.php/ISCSI_Target#Setup_with_LIO_Target I don't know why people want to use but not maintain the original packages. Debian still uses the original variant, that alone is reason enough to have the option to use the original on Arch Linux. Long talk short: No, I don't think orphaned packages should be deleted. -- JonnyJD PS: for anybody interested in these particular PKGBUILDs: https://github.com/JonnyJD/PKGBUILDs/tree/95f6d672ccf9baa151a9287a35b6f32807...

Ivy Foster

3:05 p.m.

On 11 Aug 2015, at 3:48 pm +0200, Johannes Dewender wrote:

...

[snip]

...

I uploaded both to AUR3 and also to AUR4. I maintain the free branch, because I think this is the better variant. Having the original on AUR would be good, so I also updloaded these, but I personally don't want to maintain these.

...

There are however some users that still want to use the original. There aren't many changes either, since the original doesn't have releases often. (the free branch has lots of releases)

If and only if there is somebody who "still wants to use the original," they'll upload and maintain a PKGBUILD themselves. So it is with any package. Remember, Arch assumes a baseline of competence--or at least willingness to read--on the part of the user, and Arch's packaging tools are dead simple if you actually bother to learn them. There's no need to upload scripts to the AUR on behalf of some nebulous concept of the average user, because the average Arch user can do it themselves if they want to. Have some faith in your fellow users, and let's all work to make the new AUR less of a horrible mess than the old one. iff

Lukas Fleischer

12 Aug 12 Aug

3:16 a.m.

Hi, There seems to be quite some confusion about the package migration process and about package deletion. I would like to clarify my point of view. Hopefully it serves as a basis for discussion (i.e. technical discussion without attacking anybody personally). As already mentioned a couple of times, cleaning up the AUR was one of the incentives for having users resubmit their packages. This has several advantages: * Working packages: New users are confused when an AUR package does not build. However, packages are often broken because of being outdated or unmaintained. * Less clutter: Working packages are easier to find. Package statistics are not distorted. * Storage: Less space used for packages that do not work. On the AUR server and on mirrors. So please do not upload packages any packages to AUR 4.0.0, unless you are interested in maintaining them. If a package has not been resubmitted to the AUR 4.0.0, the maintainer did not care about it for at least two months. Please either decide to maintain such a package or wait for somebody else willing to do so. Along these lines, it might also make sense to generally delete packages that have been unmaintained for a long time. Maybe have a script to automatically remove packages that have been orphaned for a couple of months. Note that we do keep the Git repositories of deleted packages, so if anybody wants to maintain the package later, he can always clone the repository of the deleted package, fix the package and simply push it afterwards. We are also working on a command to revive deleted packages without having to add a new commit. Package deletion is equivalent to "hiding it from the website", it does not mean that the package and all its Git history are gone. Orphaning a package is a preliminary stage that only tags a package without hiding it. The "missing dependency" argument was brought up a couple of times. If you discover such a case, please contact the maintainer of the package that requires the missing package and ask him to submit it as well. You should only maintain an AUR package if you are using it, so everybody should be interested in maintaining dependencies of their packages as well (unless they are maintained by somebody else already, of course). Regards, Lukas

David Kaylor

3:40 a.m.

On Tue, Aug 11, 2015 at 11:16 PM, Lukas Fleischer wrote:

...

Hi,

There seems to be quite some confusion about the package migration process and about package deletion. I would like to clarify my point of view. Hopefully it serves as a basis for discussion (i.e. technical discussion without attacking anybody personally).

As already mentioned a couple of times, cleaning up the AUR was one of the incentives for having users resubmit their packages. This has several advantages:

* Working packages: New users are confused when an AUR package does not build. However, packages are often broken because of being outdated or unmaintained.

* Less clutter: Working packages are easier to find. Package statistics are not distorted.

* Storage: Less space used for packages that do not work. On the AUR server and on mirrors.

So please do not upload packages any packages to AUR 4.0.0, unless you are interested in maintaining them. If a package has not been resubmitted to the AUR 4.0.0, the maintainer did not care about it for at least two months. Please either decide to maintain such a package or wait for somebody else willing to do so.

Along these lines, it might also make sense to generally delete packages that have been unmaintained for a long time. Maybe have a script to automatically remove packages that have been orphaned for a couple of months. Note that we do keep the Git repositories of deleted packages, so if anybody wants to maintain the package later, he can always clone the repository of the deleted package, fix the package and simply push it afterwards. We are also working on a command to revive deleted packages without having to add a new commit. Package deletion is equivalent to "hiding it from the website", it does not mean that the package and all its Git history are gone. Orphaning a package is a preliminary stage that only tags a package without hiding it.

The "missing dependency" argument was brought up a couple of times. If you discover such a case, please contact the maintainer of the package that requires the missing package and ask him to submit it as well. You should only maintain an AUR package if you are using it, so everybody should be interested in maintaining dependencies of their packages as well (unless they are maintained by somebody else already, of course).

Regards, Lukas

Thanks for clarifying your point of view Lukas. I think some AUR maintainers are out-of-the-loop on the migration issues, for one reason or another. I suspect some simply weren't subscribed to this list over the last few months.

Daniel Micay

3:45 a.m.

...

Thanks for clarifying your point of view Lukas. I think some AUR maintainers are out-of-the-loop on the migration issues, for one reason or another. I suspect some simply weren't subscribed to this list over the last few months.

Several notification emails were sent directly rather than via aur-general.

David Kaylor

3:58 a.m.

...

Several notification emails were sent directly rather than via aur-general.

Yes, but that isn't the same thing. Being subscribed to the list would (should?) have made people aware of most of the issues surrounding the migration, including the motivations behind it and the expectations of maintainers.

Doug Newgard

3:49 a.m.

On Wed, 12 Aug 2015 05:16:03 +0200 Lukas Fleischer wrote:

...

Hi,

There seems to be quite some confusion about the package migration process and about package deletion. I would like to clarify my point of view. Hopefully it serves as a basis for discussion (i.e. technical discussion without attacking anybody personally).

As already mentioned a couple of times, cleaning up the AUR was one of the incentives for having users resubmit their packages. This has several advantages:

* Working packages: New users are confused when an AUR package does not build. However, packages are often broken because of being outdated or unmaintained.

* Less clutter: Working packages are easier to find. Package statistics are not distorted.

* Storage: Less space used for packages that do not work. On the AUR server and on mirrors.

So please do not upload packages any packages to AUR 4.0.0, unless you are interested in maintaining them. If a package has not been resubmitted to the AUR 4.0.0, the maintainer did not care about it for at least two months. Please either decide to maintain such a package or wait for somebody else willing to do so.

<snip>

Regards, Lukas

You're making one massive and incorrect assumption: that packages that don't have an official "Maintainer" listed are broken. But you have no idea why they're orphaned. In my case, I have some that I'm actively trying to get maintainers for; in the mean time, I'm looking after them even though they are listed as being orphaned. Is this not to be allowed now? Should all "orphan" packages in the official repos be deleted, just assume nobody is looking after them? I updated one package just a few days before it was randomly deleted. There's other stories further up in this thread about them being deleted after only a few hours, all with no notice. If a time limit is to be implemented, it needs to be limit long enough that the package is both unlikely to be being used and unlikely to work anymore. A month or two wouldn't cut it. A notice should also be sent out to anyone set to get notifications for that package with enough lead time for someone to pick it up. Doug

Rob McCathie

5:37 a.m.

On 12/08/15 13:49, Doug Newgard wrote:

...

In my case, I have some that I'm actively trying to get maintainers for; in the mean time, I'm looking after them even though they are listed as being orphaned. Is this not to be allowed now? Should all "orphan" packages in the official repos be deleted, just assume nobody is looking after them? I updated one package just a few days before it was randomly deleted. There's other stories further up in this thread about them being deleted after only a few hours, all with no notice. If a time limit is to be implemented, it needs to be limit long enough that the package is both unlikely to be being used and unlikely to work anymore. A month or two wouldn't cut it. A notice should also be sent out to anyone set to get notifications for that package with enough lead time for someone to pick it up. Doug

Same here. I was still monitoring the couple of packages i'd orphaned, i was hoping someone would take over maintenance. For a time at least, i'd have addressed any issues with them. Anyways, i've re-added the packages and will stay maintainer of them until things settle down a bit. -- Regards, Rob McCathie

Justin Dray

5:51 a.m.

On Wed, 12 Aug 2015 at 15:37 Rob McCathie wrote:

...

On 12/08/15 13:49, Doug Newgard wrote:

...
In my case, I have some that I'm actively trying to get maintainers for; in the mean time, I'm looking after them even though they are listed as being orphaned. Is this not to be allowed now? Should all "orphan" packages in the official repos be deleted, just assume nobody is looking after them? I updated one package just a few days before it was randomly deleted. There's other stories further up in this thread about them being deleted after only a few hours, all with no notice. If a time limit is to be implemented, it needs to be limit long enough that the package is both unlikely to be being used and unlikely to work anymore. A month or two wouldn't cut it. A notice should also be sent out to anyone set to get notifications for that package with enough lead time for someone to pick it up. Doug

Same here. I was still monitoring the couple of packages i'd orphaned, i was hoping someone would take over maintenance. For a time at least, i'd have addressed any issues with them.

Anyways, i've re-added the packages and will stay maintainer of them until things settle down a bit.

-- Regards,

Rob McCathie

I've had to do the same thing. The problem is, if it isn't orphaned, and you try to update it when you get a chance it is hard to find a new maintainer. I've never seen someone ask for maintainership of a maintained and up-to-date package before. From the reports I'm seeing as well it's a single TU deleting them all. - Justin

Bruno Pagani

7:20 a.m.

Le 12 août 2015 07:51:28 GMT+02:00, Justin Dray a écrit :

...

On Wed, 12 Aug 2015 at 15:37 Rob McCathie wrote:

...
...
In my case, I have some that I'm actively trying to get maintainers for; in the mean time, I'm looking after them even though they are listed as being orphaned. Is this not to be allowed now? Should all "orphan" packages in the official repos be deleted, just assume nobody is looking after them? I updated one package just a few days before it was randomly deleted. There's other stories further up in this

On 12/08/15 13:49, Doug Newgard wrote: thread

...
about them being deleted after only a few hours, all with no notice. If a time limit is to be implemented, it needs to be limit long enough that the package is both unlikely to be being used and unlikely to work anymore. A month or two wouldn't cut it. A notice should also be sent out to anyone set to get notifications for that package with enough lead time for someone to pick it up. Doug

Same here. I was still monitoring the couple of packages i'd orphaned, i was hoping someone would take over maintenance. For a time at least, i'd have addressed any issues with them.

Anyways, i've re-added the packages and will stay maintainer of them until things settle down a bit.

-- Regards,

Rob McCathie

I've had to do the same thing. The problem is, if it isn't orphaned, and you try to update it when you get a chance it is hard to find a new maintainer. I've never seen someone ask for maintainership of a maintained and up-to-date package before. From the reports I'm seeing as well it's a single TU deleting them all.

- Justin

That’s my exact opinion: people (including me) won’t adopt a package if everything seems OK. And adding a comment to tell users that you don’t want to maintain this anymore is not a solution: users might not be suscribed. While if it goes orphaned, tools like yaourt tell you so. All the packages I maintain(ed) where either orphaned or severely outdated when I got them, and in this last case this often involve inactive maintainer requiring disowning request. So if we don’t let people disown without deletion, we might also face increasing occurrences of this second case. Bruno

Lukas Fleischer

9:05 a.m.

On Wed, 12 Aug 2015 at 05:49:58, Doug Newgard wrote:

...

[...] You're making one massive and incorrect assumption: that packages that don't have an official "Maintainer" listed are broken. But you have no idea why they're orphaned.

In my case, I have some that I'm actively trying to get maintainers for; in the mean time, I'm looking after them even though they are listed as being orphaned. Is this not to be allowed now? Should all "orphan" packages in the official repos be deleted, just assume nobody is looking after them? I updated one package just a few days before it was randomly deleted. There's other stories further up in this thread about them being deleted after only a few hours, all with no notice.

I consider this a slight abuse of the orphan/disown functionality. Wikipedia defines orphan as [...] a child whose parents are dead or have abandoned them permanently. In my opinion, orphan packages should be defined analogously: Packages which have been abandoned permanently by their former maintainers. I didn't know that some people used package disowning the way you described it. Thanks for bringing that to my attention. Even if we disregard the etymology of the word, I still do not think that "disown but keep maintaining" is a good idea. It makes it quite hard to distinguish between "real" orphans and "maintained" orphans. Also, the maintainer information is the first point of contact when issues with the package arise. Hiding it like that doesn't seem like a good idea. So maybe we need to improve the way changing maintainership works. Having a "Give up for adoption" button (that keeps the current maintainer while allowing anybody to adopt the package) in addition to "Disown" is one possibility. I am open to other suggestions. Maybe you could at least add yourself as a co-maintainer for now. Or if you are really *actively* trying to find new maintainers, it probably wouldn't hurt if you were listed as a maintainer until you find somebody. By the way: Yes, "orphan" packages in the official repositories are deleted from time to time. We have so-called Midyear Cleanups and Christmas Cleanup where exactly that is done (although I think we didn't have them for a while for some reason)... Regards, Lukas

Sam S.

11:41 a.m.

On Wed, Aug 12, 2015 at 11:05 AM, Lukas Fleischer wrote:

...

Wikipedia defines orphan as

[...] a child whose parents are dead or have abandoned them permanently

...but new parents may want to adopt them, if given the opportunity. Deleting *long-time* orphaned packages may increase the overall quality of the AUR, but aggressively deleting them within mere hours or days (before new maintainers had a chance to find them), will have the opposite effect - because it encourages the old maintainers to hang on to packages pro-forma even when they don't actually maintain them anymore, leading to more stale packages in the AUR and no way to easily identify them. Orphaning helps smooth the process of getting a package in the hands of an active maintainer (and thus ensuring best package quality), because it: - It allows potential maintainers to discover them (through AUR helpers which show orphaned status, or by explicitly searching for orphans in the web interface - there's even a special button for it). - It encourages potential maintainers to adopt the package, by making it as painless as possible (one mouse click) rather than confronting them with a situation (inactive maintainer) where adoption might take an unknown amount of time and stress (and thus many won't bother).

...

So maybe we need to improve the way changing maintainership works. Having a "Give up for adoption" button (that keeps the current maintainer while allowing anybody to adopt the package) in addition to "Disown" is one possibility.

What is the point of the "disown" button then, if it does the same thing as "request for deletion"? There are two possible things at play here that a maintainer might want to do: 1) "I want the package to be deleted." 2) "I want a new maintainer to find this package (e.g. because I don't use this software anymore, but other users and packages still depend on it)." Until now, we could use "request for deletion" for (1), and "disown" for (2). Now that you're making "disown" work like "request for deletion", we have two redundant mechanisms for (1), and none for (2). Adding a third mechanism like you suggest is a possibility, but why not just have one for each like we did until now?

DerBaer

3:45 p.m.

...

...
So maybe we need to improve the way changing maintainership works. Having a "Give up for adoption" button (that keeps the current maintainer while allowing anybody to adopt the package) in addition to "Disown" is one possibility. What is the point of the "disown" button then, if it does the same thing as "request for deletion"?

There are two possible things at play here that a maintainer might want to do:

1) "I want the package to be deleted." 2) "I want a new maintainer to find this package (e.g. because I don't use this software anymore, but other users and packages still depend on it)."

Until now, we could use "request for deletion" for (1), and "disown" for (2). Now that you're making "disown" work like "request for deletion", we have two redundant mechanisms for (1), and none for (2). Adding a third mechanism like you suggest is a possibility, but why not just have one for each like we did until now?

I think this "Free for adoption" would be a nice feature: 1) "Request for delete" := This package is not needed anymore 2) "Request for adoption" := I will continue maintaining this package (because I think it is important), but I'd like to give it up because I don't want to do this anymore. 3) "Orphaned" := Ok, now I can't maintain this anymore (e.g. because different hardware). Someone needs to adopt is or we will delete it soon (maybe as soon as it will be outdated) Additionally: Installing an orphaned package is maybe not a good idea (outdated, ...). However "Free For adoption" just means: Only the maintainer will change soon (if someone is found), but in the meantime the package is still taken care of.

Giancarlo Razzolini

12:16 p.m.

Em 12-08-2015 06:05, Lukas Fleischer escreveu:

...

Maybe you could at least add yourself as a co-maintainer for now. Or if you are really *actively* trying to find new maintainers, it probably wouldn't hurt if you were listed as a maintainer until you find somebody.

I had some dependencies issues with some of my packages, in that they weren't resubmitted to the new AUR. I tried to contact all the former maintainers. In one case I ended up being a co-maintainer, on the others I adopted the packages. I agree with you Lukas. People are misusing the disown functionality, and expecting things to still work afterwards. I believe the problem is, and you can correct me if I am wrong, that on Aug 8th, the packages that were orphaned on the new AUR, were "hidden", as you put it. I said before, if there is someone willing to care enough for a package, they will (should) maintain it. I mentioned that arch shouldn't maintain these packages. But since you're doing it anyway, then perhaps there could be a place with all these orphaned "hidden" repos, so someone willing could search there and resubmit it to AUR if that is the case. Cheers, Giancarlo Razzolini

Doug Newgard

2:03 p.m.

On Wed, 12 Aug 2015 11:05:08 +0200 Lukas Fleischer wrote:

...

I consider this a slight abuse of the orphan/disown functionality. Wikipedia defines orphan as

[...] a child whose parents are dead or have abandoned them permanently.

In my opinion, orphan packages should be defined analogously: Packages which have been abandoned permanently by their former maintainers. I didn't know that some people used package disowning the way you described it. Thanks for bringing that to my attention.

If you want to keep to your orphan analogy, think of this more as being a foster parent or running a orphanage.

...

Even if we disregard the etymology of the word, I still do not think that "disown but keep maintaining" is a good idea. It makes it quite hard to distinguish between "real" orphans and "maintained" orphans. Also, the maintainer information is the first point of contact when issues with the package arise. Hiding it like that doesn't seem like a good idea. So maybe we need to improve the way changing maintainership works. Having a "Give up for adoption" button (that keeps the current maintainer while allowing anybody to adopt the package) in addition to "Disown" is one possibility. I am open to other suggestions.

This could work, but only if AUR helpers support it. I would image this is a very common mechanism for people to find out that a package they use is an orphan and adopt it.

...

Maybe you could at least add yourself as a co-maintainer for now. Or if you are really *actively* trying to find new maintainers, it probably wouldn't hurt if you were listed as a maintainer until you find somebody.

Many of the packages I orphaned while searching for a maintainer were picked up by someone I never had contact with. I have only been successful in my active search in a few cases, even though I had a couple of people express interest in picking them up before I orphaned them :(. As others have said, orphaning is currently the best way to find a new maintainer.

...

By the way: Yes, "orphan" packages in the official repositories are deleted from time to time. We have so-called Midyear Cleanups and Christmas Cleanup where exactly that is done (although I think we didn't have them for a while for some reason)...

Sure it does happen, but they are not deleted after a few weeks as a matter of course. My point is simply that assuming an orphan is broken and useless is premature, same as orphans in the binary repos. Doug

Doug Newgard

2:04 p.m.

On Wed, 12 Aug 2015 11:05:08 +0200 Lukas Fleischer wrote:

...

I consider this a slight abuse of the orphan/disown functionality.

Oh, and I also wanted to point out that this is just one use-case. There are others, such as the v8 package that was recently dropped from [community] to the AUR. Should the TU that dropped it not have disowned it? Doug

Sam S.

13 Aug 13 Aug

4 a.m.

...

Note that we do keep the Git repositories of deleted packages, so if anybody wants to maintain the package later, he can always clone the repository of the deleted package, fix the package and simply push it afterwards

Can you give some details on that? For example the libtiff4 package (which one of my packages depends on) was deleted, but when I do git clone ssh://aur@aur.archlinux.org/libtiff4.git all I get is an empty repository.

Justin Dray

4:19 a.m.

On Thu, 13 Aug 2015 14:01 Sam S. wrote:

...

...
Note that we do keep the Git repositories of deleted packages, so if anybody wants to maintain the package later, he can always clone the repository of the deleted package, fix the package and simply push it afterwards

Can you give some details on that?

For example the libtiff4 package (which one of my packages depends on) was deleted, but when I do

git clone ssh://aur@aur.archlinux.org/libtiff4.git

all I get is an empty repository.

I cloned one I had deleted and it was still there, I made a comment change, committed and repushed, it lost the comments and votes but the package was there. I'm not sure why yours might have failed. - Justin

3179

Age (days ago)

3181

Last active (days ago)

List overview

Download

29 comments

15 participants

participants (15)

Antonio Rojas
Bruno Pagani
Daniel Micay
David Kaylor
David Phillips
DerBaer
Doug Newgard
Giancarlo Razzolini
Ivy Foster
Johannes Dewender
Justin Dray
Lukas Fleischer
Rob McCathie
Sam S.
Simon Hanna