Python 2.7 removal outline

[Guido Falsi]

On 27/03/21 12:42, Guido Falsi via freebsd-ports wrote:
> On 27/03/21 10:44, Anatoly wrote:
>> On Thu, 25 Mar 2021 23:06:27 -0700
>> Chris <portmaster at bsdforge.com> wrote:
>>
>>> On 2021-03-25 22:24, Kurt Jaeger wrote:
>>
>>>> The portmgr@ role is a huge task and all the reasons (limited time,
>>>> dayjobs, etc) ares  valid for those folks from portmgr as for
>>>> the rest of the ports maintainers and committers.
>>> Indeed, and don't think that hadn't occurred to me. In fact I
>>> suspected that portmgr@ was feeling a bit overwhelmed, and that
>>> *that* triggered the seemingly overreaching python announcement.
>>> May I humbly request a petition for such large-sweeping changes? IMHO
>>> this will give portmgr@ the opportunity to get caught up, and perhaps
>>> get some assistance -- maybe we all come up with an idea that saves
>>> _everyones_ bacon. :-)
>> I already miss tools depending on gtk1.2, qt3, qt4 in ports.
>> Maybe it makes sense to introduce new "flag"
>> NOAUTOBUILD=    <REASON>
>> To mark the ports from which no packages should be build
>> quarterly automatically to reduce portmgr@ load, instead of just
>> dropping those ports out of ports tree? And leave all the care of those
>> ports to their maintainers, requiring them some kind of "pings" to
>> detect if maintainer is "alive" as the only criteria to keep port in
>> the tree?
>>
> 
> If I understand what you propose  you also mean that updates to the 
> ports tree infrastructure and to ports not marked "NOAUTOBUILD" don't 
> need to care if the NOAUTOBUILD ports get broken in the process.
> 
> If that is so, you can already do this.
> 
> Just create a repo on github with a port overlay, or fork the ports tree 
> git repo (just wait a few days for the migration of the official ports 
> tree to git) and you can add all the ports for old software you need and 
> maintain them, or find other people to help you doing it. If you find 
> the resources you can also provide CI and binary packages for them.
> 
> There iss no need for the project's or portmgr involvement.

OTOH, if you expect all committers to put additional work on the 
infrastructure or their ports to make sure they don't break obsolete and 
EOL software, that is not a viable option.

-- 
Guido Falsi <mad at madpilot.net>