On Apr 25, 2018, at 10: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 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
> * Using eval when {*} could be used
> * Rev bump needed when a dependency's ABI changed
> * Add --disable-werror when the build starts failing when a new version
> of clang adds a new warning
> * Fix bundled libtool that thinks 10.10 is 10.1
> * Build fails on a new OS version because of something like a missing
> #include
> * Build is missing the correct -arch flags and adding them in the right
> place is simple
I would consider many of those things to be changes that I would make even if
the port is not openmaintainer. For example, if I update icu to a new library
version, it is my responsibility to revbump all ports linking with icu,
regardless of openmaintainer.
I set openmaintainer in my ports when I don't mind others doing minor changes,
including minor updates. This presumes of course that the changes are done
correctly. openmaintainer does not mean screw up my ports. Some of my ports are
not set to openmaintainer, because they're ports that lots of other ports
depend on, and since I've maintained them for awhile, I want to ensure that any
proposed changes don't introduce build failures in less-common situations or
cause other problems that I may already be aware of but which nonmaintainers
might not have considered.
> 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.
