new ports and maintainer

[Daniel J. Luke]

On Jul 25, 2014, at 7:21 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> On Jul 24, 2014, at 5:08 PM, Sean Farley wrote:
> 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.

+1 for this.

Especially since the maintainer has signed on to handle primary support for the port(s) she/he has agreed to maintain.

> We do have exceptions where others may commit to non-open ports.

Yes - if a port is broken (build failure, upstream security release/patch) - where the smallest reasonable change can be applied immediately (although notifying the maintainer in this case is always a good idea).

If we need to change policy to make this easier (give more general exceptions, make the timeouts shorter, proactively figure out when maintainers leave, etc.) we should do so. I think this is one of two things Sean is getting at (if I understand correctly).

> On Jul 24, 2014, at 8:06 PM, Mihai Moldovan wrote:
> 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.

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

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

+1

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

I wouldn't mind responding to an email (or filling out a web form linked from an email) periodically even if there's other evidence that I'm active.

I /think/ this addresses (or starts to address) half of what Sean is asking for. The other half seems to be distaste for trac and the current ticket workflow (and reminds me of earlier conversations about moving to github). I'm pretty indifferent to that, since I think trac works well enough for the most part and am not convinced that the effort of moving to something different will really pay off in any way. I'm pretty indifferent to it, though.

Sean - did I get that right? You're suggesting that 1. Maintainer Timeout / Port abandonment procedure is too hard and takes too long and 2. trac (as currently configured) is not good enough?

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+