Python 2.7 removal outline

[Matthias Andree]

Am 25.03.21 um 16:03 schrieb Baptiste Daroussin:
>
> I really think we should as a project move forward to that direction, it does
> not even need to be driven by protmgr or even drive by any @freebsd.org
>
> I would argue here that it is even more interesting to go the gentoo way try to
> provide a tool to just server as a directory of available overlays
> with https://github.com/freebsd/poudriere/pull/798 and
> https://github.com/freebsd/poudriere/pull/797 it is even easier to public a
> light repo per overlay.

I haven't looked at the links, the general thought of providing local
overlays outside @freebsd.org subverts the purpose of a ports tree.

Look, we've been spending lots of efforts over the years to make the
ports tree accessible and customizable and a consistent experience.
Tinderbox, staging, Poudriere, OptionsNG, Pkg, Flavours (that needs some
better integration), binary package provisioning. If we now defer users
to "maintain locally" that pushes an effort that was formerly
centralized down to many people and leave them in a situation that
reduces the effectiveness of the pkg and ports setups.
It is not a solution to the issue at hand.

Olivier Certner:

> > I re-read portmgr@'s charter
> (https://www.freebsd.org/portmgr/charter/). I
> > wish it contained points about proper planning, communication and
> helping
> > maintainers and committers instead of destroying their work without
> notice,
> > even for "niche" ports. Perhaps it doesn't because this was implicit
> or taken
> > for granted. In which case, in light of recent events, it may be a
> good time
> > to revise it.

bapt:

> I will only here answer about the quality of the communication of
> portmgr, yes
> there is room of improvement in general in the current portmgr team as
> of how we
> do communicate about plans and policy and we are working on it.
Unfortunately this is not the first situation where the current or
previous portmgr@'s policy changes hit the public in a hit-and-run
style. Earlier portmgr@'s set higher standards of communicating with the
community. The decision-making does not appear transparent, and the
evaluation of consequences in some cases such as this appears
incomplete, or at least incompletely documented to the public.

If now one of the portmgr@ members, as much as I value his or her work
normally, starts justifying the Python 2.7 withdrawal outline with
untrue opinions that are sold as facts, I think your words are too weak
to describe the woe state of this particular current motion. I do
appreciate the relevant reviews.freebsd.org discussions and
preparations, but I find it inacceptable to just clear away Tauthon in
the same sweep without any discussion.

Irony contained: If our intention is to seed uncertainty among our users
and see them away in droves, then our recent management of the Python
2.7 removal is finally picking up to speed.

That, however, is not how FreeBSD used to serve its users.