What "openmaintainer" means

[Rainer Müller]

On 2018-04-25 17:10, Joshua Root wrote:
> On 2018-4-26 00:25 , Perry E. Metzger wrote:
>> On Wed, 25 Apr 2018 04:43:12 +1000 Joshua Root <jmr at macports.org>
>> wrote:
>>> On 2018-4-25 03:56 , Ken Cunningham wrote:
>>>> Waiting for the maintainer to review the ticket submission
>>>> someday often resulted in months of nothing happening, or years.  
>>>
>>> The maintainer timeout was 72 hours all along, so that's not really
>>> relevant to a discussion about the limits of openmaintainer.
>>
>> I think if you don't feel a clean version update falls in the limits
>> of openmaintainer (that is, just bumping the version and the
>> checksums), then I'm not sure what does fall under "openmaintainer"
>> for you.
> 
> Minor, uncontroversial changes. Something is broken or suboptimal and
> the fix is obvious. Specific examples:
> 
> * Typos

If a port is broken by an obvious typo, I would expect that everyone is
always allowed to commit the change to fix the port.

Requiring approval of the maintainer for a non-openmaintainer port just
leaves the port longer in the broken state.

> * Using eval when {*} could be used

OK under openmaintainer policy.

> * Rev bump needed when a dependency's ABI changed

The port would be broken without this change. Bumping the revision only
cannot do any harm. I would always allow this, even for ports without
openmaintainer.

> * Add --disable-werror when the build starts failing when a new version
> of clang adds a new warning

While the port would be broken in this case, this might also indicate
there is a need to submit a fix upstream. In many cases better left to
the maintainer.

> * Fix bundled libtool that thinks 10.10 is 10.1
> * Build fails on a new OS version because of something like a missing
> #include

These should also be reported and fixed upstream, so should go through
the maintainer.

> * Build is missing the correct -arch flags and adding them in the right
> place is simple

OK under openmaintainer policy.

> Some version bumps may be minor, others are definitely not. I would
> suggest considering the size of upstream changes in addition to those
> made to the port.
Agreed. It depends on the port what should be considered a minor update.

Rainer