Arch Linux

I've been aware of the situation for some time now, and I've been trying to come up with a "fair" way of doing this. One has to account for the fact that some packages may not release for a year or whatever, and we don't want to rip packages away from people for things like that.

In the mean time, contact the maintainer themselves, and ask about it, and if they don't respond for a while, drop a message to the tur-users mailing list, and ask a TU to make the package an orphan.

I certainly realize that there are packages that don't get updated for over a year (also for perfectly good reasons !). That's why I suggested the twofold way in my version 1): Namely _either_ update the package, _or_, if this does not apply, leave a comment "Still up to date" or similar after haveing received the automatic warning. However, it may be quite complicated to implement this.

OTOH, your mean time solution is of course also workable.

Here's my (somewhat final) proposal on how to do this, I cannot say by what version this would be implemented, as the way I'd like to do it may be somewhat involved.

1. An email should be sent to the maintainer when it is marked out of date (perhaps this should be an option, in case someone doesnt want it, added to #3059)
2. Timestamps will be implemented for out of date flags
3. A script will run once a day, any packages that have been flagged out of date for T - 1 week on that day will have another mail sent to the maintainer
4. That same script will find packages that have been flagged out of date for more than T, and orphan them

Firstly, I'd like to say that the emails should be to the effect of "please update the package, if you don't want to maintain it anymore, please disown it", secondly, my proposal for T is 1 month. That is, of course, open to argument, but I think one month is reasonable.

As for things that perhaps the maintainer does not want to update, the user flagging out of date should read the comments anyway, so the maintainer can leave a note to the effect of "please don't flag, because of blah and blah", and all should be well.

Actually, for now I'd just settle for a simple script listing the most out-of-date packages and their ages and maintainers. We could start by posting that to the TU list and see who wants to take over what. Do we also have a last login time we could correlate? That'd be handy at determining what accounts may have been abandoned.

I think, that T should be no less than 2 weeks. Maintainers will be able to get more time by switching off and on 'out-of-date' flag anyway. And most of updates are no more complicated than changing version number and generating new md5 sums.

I meant no more than 2 weeks ;p

2 weeks? we can say at least 2 months. and there should be way to get ripped packages back...
you can also check last time of user login or updating any other package. there is possibility that user is working on other packages.

And what about users which are developers also and they're contributing PKGBUILDs of their own software? there should be way to set how long you will care about package. from 1 week to 1 year from last update for example...

I think this would be a bad idea, since there are some packages that never get updated since they're never out of date. For instance -git -svn etc.

Personally, I like the 4 step auto-orphaning process. It makes sense that if a package has been flagged out of date for a long period of time (and the owner has been notified of it being flagged,) the owner most likely isn't interested in maintaining the package anymore. I can't see why there would be any objections to that. I think a month is a reasonable time frame to be considered orphaned if it's been out of date for that long without any indication of it being updated/worked on.

My thought is like the idea Simo Leone said, for a script to do it. First off, give this description so this will make sense. Lets say a maintainer signs in, where it gives how many packages the member maintains then below it, how many packages are flagged out of date. Add an additional box saying something like "Packages not updated"(within a certain time frame). Then lets say I click on the Packages not updated and when I click on a package that has been marked this way, there is an option where I could click still up2date so it wouldn't be orphaned.(of course as long as the package is still up2date). I think this would be a great way to avoid unwanted orphanage. Then we would need to decide how long of a time frame to be automaticly marked by the script.

Agreed, we already implemented out-of-date mail notifications and timestamps, so this should be easy to implement!

IMHO, there is no need to rely on a separate script to do this or have indiscriminate disowning of packages. A potential solution would be to have a series of steps that allow for any registered user to disown a specific package that has met agreed upon criteria.

1. A user flags a package out-of-date.
2. The package remains flagged out of date for x amount of time and the maintainer hasn't updated the package for y amount of time.
3. If x and y are considered long enough (at least 1-2 months?) the package page will allow any user to hit “disown package” and then adopt the package.

Such a solution would avoid disowning of packages that another user hasn't explicitly shown interest in maintaining. All while making it easier for the interested user to adopt the package without having to send something to aur-general.

Does such a solution sound convenient while still being fair?

Sounds good to me. My only fear is that some users will start misusing the flag functionality in order to take over packages...

I think that sounds like a good strategy. Lukas, I think there's that possibility, but it'd be a very boarder case for misuse.

Maybe even a period of 2 months after the package has been flagged out-of-date.

Sometimes a package is out of date because it should be though. eg Legacy packages are sometimes marked out of date because technically they are. Also sometimes you can't update because you might be waiting for a particular change upstream (or any change at all linux-sony!).
I think the current "notify maintainer, wait, email aur-general" protocol is fine. It's not ideal but I don't think any solution is because I've seen this discussed so many times!

Maybe if the maintainer set they acount to inactive the packages get never droped, but if the acount remian with the active flag the auto-disown procedure begin, and if is flag inactive for more than a week as a way to prevent spaming the active-inactive checking as minimal to stop the procedure

I have recently asked aur-general for some suggestions on how orphaning policy could be improved. This is a summary:

- auto-orphan package if out-of-date status stays longer than X (my suggestion: 1 month)
- modify the out-of-date e-mail template so the maintainer is aware the package will be auto-orphaned in X
- auto-mail the maintainer one week before X
- "Notify of orphaning" link in "Package Actions" so interested people can know once the package has been orphaned (related to https://bugs.archlinux.org/task/15412)
- daily digest e-mail of orphaned packages sent to aur-restests ML

Full thread: https://mailman.archlinux.org/pipermail/aur-general/2014-May/028506.html