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 are > encouraged to claim maintainership or revert it to [email protected] under > the 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.
