new ports and maintainer

[Sean Farley]

Daniel J. Luke writes:

> On Jul 24, 2014, at 4:55 PM, Sean Farley <sean at macports.org> wrote:
>> 
>>> I, for one, appreciate the ability to specify which ports I don't care if people apply patches to vs. ports where I'm very careful about updating/keeping things from breaking.
>> 
>> Well, the problem is people still commit on your ports.
>
> they do?

I've seen it happen here on the mailing list.

> I've found that it's very rare that someone touches my non-openmaintainer port(s)
>
>> 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?

In this sense, I meant auditing to just be port maintenance without
having access to inside your thoughts.

> it's worth nothing that the complexity of an individual portfile is generally pretty low (as it should be).

Yes, so why have the exclusivity?

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

Possibly but exclusivity for portfiles doesn't help people get involved
with learning how to maintain other ports.

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

Not in general, no. How many times has someone done a search-and-replace
and notified others beforehand? I've seen it maybe once or twice, tops.

> You open a ticket (with a patch) assigned to the maintainer who then reviews it before it's committed.

If trac were integrated to work closer with the repository, I'd be
inclined to drop this point, but it's not. Getting patches through the
browser or some random script is a pain, at best. The worst part is that
you get one giant diff instead of seeing the commit history.

>> This
>> is kind of what Ryan and other core devs try to do by reviewing the
>> mailing list of changes but would now allow them (and other reviewers)
>> to stop before a change is integrated.
>
> which is the opposite of just letting anyone with commit access commit changes (which is what openmaintainer says).

Yes, I was proposing a pull-request model (just as an example, though)
where there would be a small number of integrators.

>> Honestly, I think you'd be better served by having a comment say "please
>> run changes past <email address / macports-dev> before committing."
>
> and again, that's how non-openmaintainer ports work (ie, if you email me a diff/patch/change for subversion - I'll review it and either apply it, modify it and apply it, tell you to apply it, or discuss why we may not want to apply it as-is ... I follow the same process if you open a ticket and assign it to me, which is better since it's stored where others can see it).

What I'm trying to do is develop a way to encourage more involvement.
So, instead of engaging a macports devevloper separately, the whole
community can be involved.

I think however you slice this, openmaintainer is not needed. Either
there are no other reviewers (nomaintainer ... would we really need to
list this?) or there are others to ping.

It would a long ways (a really, really longs way) if trac were better at
code review, automatically assigning reviewers to an issue, and
automatically closing tickets. But these are worthy of their own thread
of discussion.