Am 26.09.2011 um 21:07 schrieb Ryan Schmidt: > On Sep 26, 2011, at 13:26, Jordan K. Hubbard wrote: > >> On Sep 26, 2011, at 2:51 AM, Rainer Müller wrote: >> >>> On 09/24/2011 10:53 AM, Titus von Boxberg wrote: >>>> I followed http://guide.macports.org/#project.membership >>>> to apply for commit rights but didn't receive an answer on two mails. >>>> >>>> Is this due to a technical or personal or documentation problem? >>> >>> You did nothing wrong and that is the correct procedure to apply for commit >>> access. We as managers would be supposed to review your request, but over >>> the last month nobody got to it. This review includes looking for tickets >>> in Trac, Portfile contributions, submitted patches, mailing posts and so >>> on. After that, we still need to make the decision if we grant the commit >>> access or not. >> >> That certainly wins points for honesty and clarity (seriously), but it still >> leaves the poor guy hanging somewhat on the "what next?" question. Is >> there some procedure for what happens when portmgr is unresponsive? Can one >> of you make unilateral decisions on its behalf, or is a quorum required, or >> ... ? These might be good questions to at least discuss amongst >> yourselves. :) > > I believe the procedure when portmgr is unresponsive is to keep poking us > until we respond. Usually one of the managers will initiate a conversation > among the managers, proposing the application be accepted or rejected. > Sometimes there is further discussion, sometimes not. After a consensus is > reached, or if there is no further discussion, someone usually then acts on > the request.
Would it be worthwile to install an org.macports.pokemgrs.plist? What StartCalendarInterval would be recommended? Maybe you, the mgrs, could define separate responsibilities and assign roles to reduce the output of `grep -Ece 'some|any|usually'` in your procedure description. Just as Ryan seems (from the mails that I see passing by) to be the master of changeset quality assurance, maybe someone of you could chair granting/revoking commit rights. Just a cheap idea. Doesn't have to be Total Quality Management + Six Sigma in the first step ;-) And, kindof coincidence, exactly that poking is why I applied for commit rights: I feel that an appreciable ratio of the (admittedly not so many) issues I brought up or fixed or somehow contributed to required poking (NOT discussing). It seems to have improved over the last year or so, the mails "could someone commit this" seem to get fewer, but as I do not have other statistics available that might be just for any reason; if observed correctly at all. Don't get me wrong, I'm not blaming you or anyone else for this. It's simply that I do not feel that poking is my job here any longer (than now for 1.5y). I'd either use macports as a nifty installer for a private port tree of things that I need. Or get commit rights for the mostly trivial Portfiles or patches (suffering from maintainer timeout) that I'm able to contribute in my spare time. Regards Titus _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
