On 2026-10-27 01:22, Gleb Popov wrote:
On Tue, Oct 27, 2026 at 2:04 AM Robert Clausecker <[email protected]> wrote:Dear portmgr, In light of today's ports removal I feel like we need to improve the process around broken ports a bit. Diizzy's actions reflect a common failure mode we see in the tree: - maintainer falls absent - port falls into disrepair and breaks - nobody is alerted of the breakage and those who notice believe that there is a maintainer and do not take action - eventually someone notices that the port has been broken for *very long* and removes it outright (permitted within policy) I propose the following policy changes to improve the situation: - Committers are encouraged to mark ports that do not build anywhere as BROKEN if they believe the breakage reason to be of a kind that will not resolve itself shortly (e.g. temporary mirror outage). If the port is only broken in some configurations (some OSVERSION, some ARCH), the appropriate BROKEN_${ARCH} etc. should be used. When in doubt, committers can check the pkg repos or freshports for binary package presence to ascertain whether the port builds in any configuration - A new variable BROKEN_SINCE= YYYY-mm-dd is added, which should be set to when the breakge was first noticed when the port is marked as BROKEN. It should not be set for BROKEN_*, only for complete breakage. This is when *you* the committer noticed that the port was broken.FWIW, I do not like the new knob. BROKEN_SINCE can be inferred from the "git blame" output, locating the commit that added BROKEN.- Before marking the port as BROKEN, check if there are any patches around that could fix it. Prefer applying such patches under build fix blanket approval over marking the port as BROKEN. This is not a mandatory step, but you are strongly encouraged to follow it. - Make sure to commit BROKEN and BROKEN_SINCE without delay once you notice the breakage. - Three months from BROKEN_SINCE, maintainership reverts to [email protected] except in the case of group maintainerships. At the same time, an EXPIRATION_DATE is added three months from that date. This process should be automated by means of a cron job.What about active maintainers that deliberately marked their ports BROKEN? For example, waiting for a new release upstream that will fix the issue?- Broken ports may only be removed without going through this process or without maintainer approval (this may be through maintainer timeout) if they are clearly beyond rescue. This includes cases like * The port is only available for an architecture that is no longer supported. * The port requires an OS feature that is no longer present and that cannot be supplied as a third-party dependency. * The port is not legally redistributable. * Upstream has requested we do not ship the port. * A mandatory dependency of the port has been removed and the port cannot be patched to no longer require it.* The port is unfetchable and it will not be possible to make it fetchable.Please follow the BROKEN process for unfetchable ports unless you are absolutely sure that no new upstream / hoster will ever be found. - Committers and third-party contributors are encouraged to step up and fix BROKEN ports under the established build fix policy without explicit maintainer approval. If they find the maintainer to be absent, they areencouraged to claim maintainership or revert it to [email protected] underthe standard policies for maintainer timeout and absentee maintainers. - A port that is deleted and re-added must follow the same rules as any other new port. In particular, there must be a maintainer who has explicitly agreed to maintain the port. This can be a group maintainership.Fully agree.
I'm with Gleb here. I've always found the BROKEN, DEPRECIATED timeouts to be fairly intuitive. Do others not? I appreciate your clarifying the terms here this last section. Maybe adding it to the porters handbook makes the current timeouts clear enough? Thanks, Robert. :) --Chris
0xE512722F.asc
Description: application/pgp-keys
