It's a slang usage, but it's common enough that everybody treats it as a respectful gender-neutral term.

"Their" in a singular context is pretty awkward grammar. "His or her" is the correct phrase, but you could avoid it entirely with "all ports maintained by that [person/address/individual]" or "all of that maintainer's ports."

In D15776#333672, @mat wrote:

Well, it was the idea, if someone is gone and not interested any more, no point in keeping them as dead maintainers.

Anyone can submit a PR with a patch changing the maintainer of a port, and that patch can be committed after a single timeout.

True, but the new text removes resetting maintainership on a single port entirely. Now, if ANY port times out, it calls for ALL ports to be reset.

That's a very good point. Perhaps "made no contributions (commits, submissions, or PR comments)" instead.

We need to clarify whether "three consecutive timeouts" refers to "three consecutive timeouts of one port" or "three consecutive timeouts in any port owned by this maintainer."

I definitely like this. Thanks, @mat!

In D14253#299275, @yuri wrote:

Ok. So it sounds like it is safer to just always bump dependencies when the shared library changes? Because we usually really don't know what actually changed in shared libraries.

Before committing, please make sure that it passes portlint (I don't know if there's an option _DESC length max) and that the whole message is viewable. If not please shorten it however you see fit.

sqlite updates don't usually need an exp-run. The upstream regression tests are comprehensive and there are almost never breaking changes. I think your gut instinct is good---normally a port this important should have an exp-run. sqlite is generally pretty safe though.

Approved, with the changes to the message text.

In D14200#297813, @yuri wrote:

Since it hasn't been added to VuXML before, should anything be done for this now that it is fixed?

This will need a VuXML entry and an MFH, no?

Not all mirrors update at the same frequency. It's not uncommon (when following head) to go 10 mirrors down before one fetches.

In D14194#297712, @daniel.engberg.lists_pyret.net wrote:

• 8-10 (mirror)-sites in total, fall back to main site as last resort
• HTTPS (where possible) --> HTTP --> FTP (in that order)
• Prioritize fast mirrors in general with good connectivity (peering/backbone) for NA/EU users however provide at least 2 mirrors in Asia for connectivity and availability if possible