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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev