new ports and maintainer

[Mihai Moldovan]

* On 25.07.2014 01:21 pm, Ryan Schmidt wrote:
> On Jul 24, 2014, at 8:06 PM, Mihai Moldovan wrote:
>> [...]
>>
>> # TIMESTAMP: openmaintainer prohibited.
>>
>> [...]
>
> 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.

* On 25.07.2014 03:50 pm, Daniel J. Luke wrote:
> +1 for this too. I have at least one non-openmaintainer port that went ~9 years between upstream releases - I'm not going to remember to check in a mostly meaningless timestamp update every 6 months just to keep it non-openmaintainer.

It is busywork.  However, I find it very unlikely that a port doesn't get
changed at least once every 6 months. Maybe not for updates, but because
dependencies require a revision bump, a new OS version came out requiring a
quick fix, or just because base evolved.


> 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.

That's a good idea, as long as openmaintainer stays a recommendation and not a
requirement.


> 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.

Manually sending out mails and processing answers is not going to fly. Not with
the huge maintainer list there is.

Automatically determining inactive maintainers by your outlined criteria and
sending out surveys on the other hand sounds good. At the same time, replies
will also have to handled automated, I cannot believe one or several people
could handle the burden of keeping track of answering or not answering
maintainers. Compared to just updating a timestamp, this is far worse busywork.

I like that idea very much though and think it's the way to go. There's just one
problem with it.

It sounds complicated to write scripts doing of all this. You'd have to hook
into the mailing list, query the Trac database backend directly (the website has
no means of searching for comments made by a specific user), keep a list of sent
mails, update that on replies and decide and implement timeout measures.

This probably could qualify as a GSoC project, alongside adding an option to
Trac to be able to search for comments made by a specific address.

Given MacPorts is understaffed as it is, I don't see something like this being
implemented, up and running in just a few hours.



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4265 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140725/8fc68fa3/attachment.p7s>