new ports and maintainer

[Ryan Schmidt]

On Jul 24, 2014, at 5:08 PM, Sean Farley wrote:

> Yes, so why have the exclusivity?

The maintainer is supposed to hold the consolidated knowledge of that software as relates to building it within MacPorts, and may have very good reasons for why a port does or does not do something and doesn't want it changed by someone who may not be aware of all the implications. For example, I've received numerous requests to reinstate the "hdri" option for the ImageMagick port, but we *cannot* add that option without breaking binary compatibility, which is why the option was removed and will not be re-added until some future major restructuring of ImageMagick into separate subports for such ABI-changing options. Also, some ports are very important, because they are depended on by lots of other ports; I don't want an inexperienced developer committing an incompletely-considered change to e.g. gettext that breaks half of MacPorts.

We do have exceptions where others may commit to non-open ports. For example, I updated libgcrypt to 1.6.1 recently, which changed the library version, so it was my job to also revbump of all dependent ports so that they would not be broken. In some cases, this involved also having to update a dependent to a newer version or apply a patch to ensure continued successful building. If I had to update a port's version I would probably want to have maintainer approval first; IIRC the only ports I updated in this case were mine or nomaintainer.


On Jul 24, 2014, at 8:06 PM, Mihai Moldovan wrote:

> 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
> change".)


I do not want to have to update a timestamp in every portfile periodically. That's just busywork. We have other ways to see if a maintainer is active.

I agree we have a problem with maintainers disappearing and it taking some time for us to notice and react. But we do have a port abandonment procedure, and I would instead focus on improvements to that procedure, and better maintainer education. For example, we could improve the port abandonment procedure to include all other ports by the same maintainer; that's how I usually file the tickets anyway. We could mention in the guide what our expectations are when a maintainer no longer has the time or interest for maintaining. We could recommend the addition of openmaintainer when someone assumes maintainership, especially for non-committers. We could include information on how to retire in the email that management sends to approved committers.

There was a recent discussion about manually sending out a maintainer survey, but it would be nice not to bother maintainers who are clearly active. We could develop an automated way to survey maintainers about their continued involvement. An automated system could estimate a maintainer's level of current involvement in the project by checking for tickets filed, commits made, mailing list posts sent, and only send such emails periodically to developers who have not been active in the last 3 months, say. A maintainer could reply to such an email to indicate whether they are still active; a "no" response or multiple unanswered emails could trigger the port abandonment procedure, e.g. by automatically filing a port abandonment ticket or even by automatically removing them as maintainer of their ports.