new ports and maintainer

[Sean Farley]

Mihai Moldovan writes:

> * On 24.07.2014 11:49 pm, Daniel J. Luke wrote:
>>> Unless you've
>>> left comments in your portfiles, then there's no auditable way to
>>> maintain your ports if, say, you stop being a maintainer.
>> I can't parse this sentence. "no auditable way" what are you auditing?
>
> Don't nitpick. :)
>
> He means that there is no reliable way to determine whether a maintainer has
> stopped contributing or is just taking a break for a week or two or ...

Yes, thank you.

>>> I would instead like to encourage better practices rather than "don't
>>> touch my port" which, I believe, leads to bottlenecks for fixing
>>> tickets. 
>> this isn't something we have to rely on 'belief' for - we could actually measure response time on tickets. I would suspect that there are easier ways to fix the problem you're outlining (maintainer timeout) without having to go so far as to say "no more exclusive maintainer"
>
> Unless you want to implement functionality like that in Trac, which probably is
> very painful to integrate anyway, there really isn't no good way of measuring
> maintainer response.

I will comment again that Trac is a big pain and it seems that most the
work involved in the macports community goes into the same tedious
tasks:

- correct the 'owned by' field of a ticket
- correct the CCs
- tell the user to upload log files
- tell the user to upload a unified diff
- fix formatting
- periodically go through and close tickets

> That's what Sean is aiming at and he's right, to my mind.

:-)

>>>> Ultimately, I'm not willing to provide active support for something that lots of other people are going to (potentially) be updating (and, in general, I prefer to get prior notice of a possible change before it hits the repo).
>>> Ideally, we'd have a pull request or code review model where you (and
>>> whomever else is listed in the portfile) would be notify to review.
>> um, that's how non-openmaintainer ports work.
>>
>> You open a ticket (with a patch) assigned to the maintainer who then reviews it before it's committed.
>
> Pretend the maintainer(s) stopped doing work and even checking mail. Waiting for
> a timeout unnecessarily prolongs the fixing period.
> I'd prefer just force-pushing the change, even if the port is non-openmaintainer.
>
>
>>> Honestly, I think you'd be better served by having a comment say "please
>>> run changes past <email address / macports-dev> before committing."
>
> Actually, this spawned another idea in my head.
>
> What about this: we keep openmaintainer and its absence as-is.
>
> 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".)
>
> Even if bumping is forgotten, no harm done, anyway. The change is easily revertible.
>
>
> What do you guys think?

This is one possible way to do it. I would add that 'openmaintainer'
really isn't needed. Either the portfile has a '# TIMESTAMP: due to
reason (hopefully link to an issue)' or it doesn't.

Honestly, I think we just need a better code review process instead of
creating fiefdoms for the portfiles.