<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 11/30/25 15:14, Jeremy Hansen wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANi9qSt3V-2K+fMyaSq=wTjtWWBcDNOUp7ZXkojJeSJ+HcUPBg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">
        <div><br>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Sun, Nov 30, 2025,
              12:05 PM Glenn <<a
                href="mailto:glimrick@epilitimus.com" target="_blank"
                rel="noreferrer" moz-do-not-send="true"
                class="moz-txt-link-freetext">glimrick@epilitimus.com</a>>
              wrote:<br>
            </div>
            <blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On
              11/29/25 22:42, Jeremy Hansen wrote:<br>
              > Personally, I think 1 year of inactivity of the
              author is reasonable, <br>
              > however, I do realize we have more than half the
              maintainers only <br>
              > maintaining a single script, and some of those
              programs might have <br>
              > years between their releases, which their maintainer
              is tracking.<br>
              <br>
              I've read the official reply but this spawned a thought
              that might be <br>
              useful in the general case. How about basing it on number
              of releases? <br>
              If the package authors have made N releases with no update
              from the <br>
              maintainer, and the maintainer doesn't respond to queries
              within a <br>
              reasonable time period then it is up for grabs.<br>
            </blockquote>
          </div>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">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. </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">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.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">@ 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...</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Jeremy</div>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre wrap="" class="moz-quote-pre">_______________________________________________
SlackBuilds-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:SlackBuilds-users@slackbuilds.org">SlackBuilds-users@slackbuilds.org</a>
<a class="moz-txt-link-freetext" href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a>
Archives - <a class="moz-txt-link-freetext" href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a>
FAQ - <a class="moz-txt-link-freetext" href="https://slackbuilds.org/faq/">https://slackbuilds.org/faq/</a>

</pre>
    </blockquote>
    <p>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. </p>
    <p>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.</p>
    <p>I admit it would take a bit of time but it would also prevent
      some hard feelings from toes getting stepped on.</p>
    <p>In any case it was just an idea, thought I would put it out as an
      option.</p>
    <p><br>
    </p>
  </body>
</html>