new ports and maintainer

[Sean Farley]

Daniel J. Luke writes:

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

Yes. Consolidated knowledge is something that is hard to manage and
share. The best I've seen how other projects deal is to leave
constructive and helpful comments as to why something is done the way it
is.

Admittedly, that is a lot of work.

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

Yes, indeed. That's something I was trying to get at.

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

Updating some timestamp is doomed to fail.

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

Yes, improving this procedure would be great and go a long ways, I think.

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

How about we just have a policy (or just a community understanding) that
if a developer timed out (for whatever reason) and then comes back, that
he/she can re-add their name?

This would be something akin to garbage collection in a programming
language :-)

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

Yep, pretty much. It took a while (since I was traveling) to collect my
thoughts on the matter and respond. One of my points is that there is no
real difference between 'openmaintainer' and 'nomaintainer'. One has
other devs listed, the other does not, so why not combine the names?
It's easy enough to see that if 'openmaintainer' is listed and no one
else listed, then that port has no actual maintainer.

1. Ideas for improving maintainer timeout would be welcomed. Currently,
   it's haphazard and hit-or-miss.

2. Trac fails for many reasons. The biggest failure is the context
   switch required to open up a web browser. The lack of good command
   line tools, ability to respond via email, and automatically close
   tickets are deal breakers.

Perhaps an email thread should be started for (1) and (2)?