new ports and maintainer

Mihai Moldovan ionic at
Thu Jul 24 18:06:48 PDT 2014

* On 24.07.2014 11:49 pm, Daniel J. Luke wrote:
>> Unless you've
>> left comments in your portfiles, then there's no auditable way to
>> maintain your ports if, say, you stop being a maintainer.
> I can't parse this sentence. "no auditable way" what are you auditing?

Don't nitpick. :)

He means that there is no reliable way to determine whether a maintainer has
stopped contributing or is just taking a break for a week or two or ...

>> I would instead like to encourage better practices rather than "don't
>> touch my port" which, I believe, leads to bottlenecks for fixing
>> tickets. 
> this isn't something we have to rely on 'belief' for - we could actually measure response time on tickets. I would suspect that there are easier ways to fix the problem you're outlining (maintainer timeout) without having to go so far as to say "no more exclusive maintainer"

Unless you want to implement functionality like that in Trac, which probably is
very painful to integrate anyway, there really isn't no good way of measuring
maintainer response.

That's what Sean is aiming at and he's right, to my mind.

>>> Ultimately, I'm not willing to provide active support for something that lots of other people are going to (potentially) be updating (and, in general, I prefer to get prior notice of a possible change before it hits the repo).
>> Ideally, we'd have a pull request or code review model where you (and
>> whomever else is listed in the portfile) would be notify to review.
> um, that's how non-openmaintainer ports work.
> You open a ticket (with a patch) assigned to the maintainer who then reviews it before it's committed.

Pretend the maintainer(s) stopped doing work and even checking mail. Waiting for
a timeout unnecessarily prolongs the fixing period.
I'd prefer just force-pushing the change, even if the port is non-openmaintainer.

>> Honestly, I think you'd be better served by having a comment say "please
>> run changes past <email address / macports-dev> before committing."

Actually, this spawned another idea in my head.

What about this: we keep openmaintainer and its absence as-is.

However, non-openmaintainer ports are required to insert a comment in the
Portfile, reading something along those lines:

# TIMESTAMP: openmaintainer prohibited.

TIMESTAMP could be something like 20140725.

A script could periodically go through all Portfiles and examine them regarding
this comment. If the timestamp is, say, older than six months, it is removed and
openmaintainer forcefully added.

Port maintainers are required to increase the timestamp on each change (or at
least often enough to prevent escalation to openmaintainer. I don't literally
mean each change. For rarely updated ports, it will effectively be "on each

Even if bumping is forgotten, no harm done, anyway. The change is easily revertible.

What do you guys think?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4265 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the macports-dev mailing list