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.
- 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.
- 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. In case of an absentee maintainer, this can only be
the old maintainer if he was successfully contacted or reached out on
his own, agrees to be maintainer and is able to convince the committer
to re-add the port that he will follow through with maintaining. It is
at the committers discretion to ascertain this commitment. When in
doubt, a different maintainer must be found
Please discuss. If this proposal is well received, I would like to submit
these ideas for voting in about two weeks.
Yours,
Robert Clausecker
--
() ascii ribbon campaign - for an encoding-agnostic world
/\ - against html email - against proprietary attachments
