It seems like the interested people fork MacPorts just before the commits that remove 10.4 and focus on supporting that for the legacy funtime use case. Let that fork of Macports age gracefully with the hardware that supports it. Reducing the burden of keeping current macports up to date and functional is significantly more critical in my view.
> On Feb 11, 2025, at 7:11 AM, Sergey Fedorov <vital....@gmail.com> wrote: > > Just for a note, there is no problem in explicitly stating that no tickets > for 10.4 will be accepted and just close such tickets as wontfix. > (And Ken, for example, recently went as far as closing as wontfix all tickets > for bugs discovered on 10.6 PowerPC even when those had not been specific to > either 10.6 or PowerPC and affected 10.4–10.5 as well.) > > There was nearly no active support for any PowerPC systems for years anyway > (outside of legacy-support subproject), and most of PowerPC-related fixes > were from my side (which I now stopped submitting here). > > So ripping 10.4 support from the base was indeed unnecessary and rather > symbolic than driven by any practical considerations. > > At the same time, at least the ports tree was not fully functional on 10.4 > for quite a while, I believe. So given that in any case users will require > either a full fork or at least a local overlay to have MacPorts working, > nothing changes much. > > It would be nice if MacPorts upstream at least followed Homebrew in a sense > of formally referring users to a PowerPC-specific fork, or, better, keep such > fork under MacPorts (but with separate maintainership), but when I suggested > the latter, there was no enthusiasm. > > Serge > On Feb 11, 2025 at 00:34 +0800, Christopher Nielsen > <masc...@rochester.rr.com>, wrote: >>> I think dropping support for Tiger in this way is quite heavy-handed. I’d >>> like to ask for a compromise, where Tiger stuff is maintained on a >>> volunteer best-effort per-issue basis rather than entirely ripped out. >>> >>> I understand that maintaining Tiger causes some overhead. Only a subset of >>> packages build on Tiger and that's OK. Trac issues can be closed as wontfix >>> or ignored until somebody volunteers to fix them. Breaking Tiger >>> accidentally shouldn't block anyone but please do not break it deliberately. >> >> I’m a bit behind on responding to the entire “Should we remove support for >> Tiger” topic, due to work and personal commitments. So I’ll add my two cents. >> >> Ideally we would have kept this discussion open for at least a few weeks, to >> allow time for busy individuals to chime in. That’s not meant as a criticism >> of anyone, but just throwing that out there. >> >> Had there been a formal vote on whether we remove support from base, I’d >> probably lean toward keeping it for now. (Though I can understand the desire >> to simplify base wherever and whenever possible.) So it’s not an easy >> decision by any means. >> >> It’s also important to separate our support policy toward Tiger - which is >> to now de-emphasize it - from what base supports. And that seems to have >> been lost, or perhaps not really discussed as thoroughly as we might like. >> And perhaps this is the disconnect, as I’m also somewhat surprised it was >> removed so quickly following the support policy change. >> >> Ultimately the fact that MacPorts still supports Leopard and above, is >> awesome! And hopefully we can continue to do so for a few more years, given >> the amount of enthusiasm and interest in keeping older hardware working and >> functional. >> >> Personally I’m fine with continuing to support Tiger, so long as it doesn’t >> become an undue burden on maintainers. And for the most part, it generally >> hasn’t been too bad. (With some occasional exceptions.) Though Ryan is >> right, in that a fair number of our support tickets do relate to Tiger and >> Leopard. >> >> So I don’t know what the best approach is, but spirited discussion and >> engagement is always a good thing. To be continued... >> >> -Chris
