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. _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
