Hi all,
Robert's proposal touches a real problem: ports that stay BROKEN for
months while nobody feels responsible. Releasing such ports to ports@
can help, because it makes clear that anyone may step in and fix them.
To Gleb's point, it should not hit active maintainers who set BROKEN
on purpose while waiting for an upstream release.
What I miss in this thread is the order of steps. Most of the
discussion is about when a port may be removed. Shouldn't the first
goal be to fix it?
If a project is dead, for example the repository has seen no activity
for years and the code no longer builds, there is nothing wrong with
removing the port. If the project is alive, the port should get the
chance to be fixed first. For Budgie, the fix had been available
upstream since November 2025 (10.9.4). For filesystems/darling-dmg, a
patch had been waiting in Bugzilla since September 27 (PR 298920),
and the maintainer timeout had already expired. Both ports were
removed anyway. Restoring, fixing and testing both took one evening,
which is less time than all of us have spent on this discussion.
These are not isolated cases. On October 4, 19 and 26 alone, 27 ports
were removed from the tree in 21 commits because they were marked
BROKEN. None of them had been deprecated with DEPRECATED and
EXPIRATION_DATE first. Two of them were not even broken themselves,
they only depended on a broken port. Users of these ports had no
chance to speak up.
To be fair: nobody, including me, submitted a PR for Budgie during
the five months it was BROKEN. That is exactly the gap the deprecation
step is meant to close. BROKEN alone is not visible to users,
DEPRECATED with a PORTREVISION bump is.
mat@ (portmgr) published the "Maintainer Load and Port Lifecycle
Policy" on August 18, 2026:
https://wiki.freebsd.org/Ports/MaintainerLoadAndPortLifecyclePolicy
As I read it:
1. Section 5 puts all grounds for deprecation under the condition
"unless someone steps up to fix the underlying issue". Being
BROKEN is not listed as a reason on its own, and it states:
"Absence of activity or reverse dependencies is not, by itself,
sufficient grounds for removal."
2. Section 6 describes the procedure: set DEPRECATED with a reason
and an EXPIRATION_DATE, bump PORTREVISION so users see the notice
on upgrade, and merge the change to the current quarterly branch.
The default period between setting EXPIRATION_DATE and removal is
30 days. mat@ confirmed in this thread that this also applies to
ports depending on the deprecated port:
https://lists.freebsd.org/archives/freebsd-ports/2026-October/010390.html
The Porter's Handbook (13.15) says permanently broken ports will be
removed, but leaves the warning optional. The policy makes it
mandatory.
Two practical suggestions:
1. Before removing a BROKEN port, check Bugzilla for open PRs against
it. A pending patch means the port is not beyond repair.
2. Whether a port is removed and who maintains it are two separate
questions. For an absent maintainer we already have maintainer
timeouts and the reset to ports@. A port that was removed without
going through section 6 should simply be restored, not handled
like a new port.
Regards,
Jochen
Am 27.10.26 um 09:22 schrieb Gleb Popov:
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.
