What "openmaintainer" means

Mojca Miklavec mojca at macports.org
Wed Apr 25 17:13:28 UTC 2018


Hi,

I've been wanting to ask for a long time already: wouldn't it be about
time to start switching to an explicit "closed maintainer" policy
instead?

That is: having to explicitly declare ports to be under a closed
maintainer policy, while keeping openmaintainer as default otherwise.
Of course that means having a transition period until all ports define
either one or the other, and only then drop the openmaintainer
keyword.

What's currently slightly suboptimal is that many new contributors
create a new port and put their name on them. It feels strange to
explain to each one of them that they should probably put an
"openmaintainer" label to their new port, most likely keeping many of
them somewhat offended. For maintainers without commit rights (and
potentially just submitting something and never returning back) it's
additionally problematic.

This leads to many ports being under "closed maintainer" policy "by
mistake", very often those are in fact even abandoned ones, forcing
other developers to have to use maintainer timeout to do any changes
(or often not do any changes at all because they forget or no longer
care by the time they would be allow to make the change), as well as
spreading a general subconscious belief that it's just OK to mess with
closed maintainer ports.

We could potentially define a different keywoard instead of misusing
the "maintainer" keyword.

And if there's a need, we could of course define more levels of "how
closed" a port should be. This is another case where for a lot of
software updates are usually trivial, while for others it may break
your system (say, when software switches from C++98 to C++17 and
completely changes the API :), so the question of whether an update
counts as a trivial update probably varies wildly from one port to the
other.

>From my personal perspective: I want to keep most of my ports
openmaintainer because I want others to contribute and neighter want
nor need exclusive rights over ports. But there might be cases when I
have a bunch of changes pending, or I know that a bunch of dependent
ports will break after update ... which is why I still appreciate that
people don't just randomly commit changes behind my back. A PR giving
me more than 24 hours time to go through the changes (to at least be
informed and have time to object) is helpful.

Mojca


More information about the macports-dev mailing list