[Slackbuilds-users] Author Inactivity Threshold Question Regarding Takeovers

[Glenn]

On 11/30/25 15:14, Jeremy Hansen wrote:
>
>
> On Sun, Nov 30, 2025, 12:05 PM Glenn <glimrick at epilitimus.com> wrote:
>
>     On 11/29/25 22:42, Jeremy Hansen wrote:
>     > Personally, I think 1 year of inactivity of the author is
>     reasonable,
>     > however, I do realize we have more than half the maintainers only
>     > maintaining a single script, and some of those programs might have
>     > years between their releases, which their maintainer is tracking.
>
>     I've read the official reply but this spawned a thought that might be
>     useful in the general case. How about basing it on number of
>     releases?
>     If the package authors have made N releases with no update from the
>     maintainer, and the maintainer doesn't respond to queries within a
>     reasonable time period then it is up for grabs.
>
>
> My goal was to see if there was a threshold of inactivity that didn't 
> require reaching out to the maintainer and waiting a week or two for a 
> response and then asking the admins through the list to take over due 
> to no response... you just submit an update stating you're taking it 
> over due to X years of inactivity from the author.
>
> If there was an official policy, it would simplify taking over 
> abandoned (but never orphaned) builds and could lead to updates pushed 
> weeks earlier than they normally would be. I do understand that it 
> would be hard to capture this cleanly in a "one size fits all" policy 
> that B. Watson mentioned, I was just hoping they already had something.
>
> @ B. Watson, thanks for that. I guess I should search my email when 
> checking on an inactive author to see if they've already posted about 
> it...
>
> Jeremy
>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives -https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ -https://slackbuilds.org/faq/
>
I agree with your objective. My rationale for basing it on a number of 
releases without an update is that it would allow for mature projects 
which have few widely spaced new releases, as well as young projects 
which tend to have a much higher release rate. Using a number of 
releases without update would cover both without tying it to an amount 
of time.

As  for waiting for a response from the maintainer, I added that in case 
the maintainer was just about to make an update. My approach would be 
the person wanting to take over would do the research, checking how many 
unsupported releases there have been and reaching out to the current 
maintainer. If they don't hear back in say a week, or the message 
bounces, then they pass their findings along to the admins who make the 
decision.

I admit it would take a bit of time but it would also prevent some hard 
feelings from toes getting stepped on.

In any case it was just an idea, thought I would put it out as an option.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20251130/64b5c2f7/attachment.htm>