What "openmaintainer" means

[Michael Dickens]

Great discussion!

My preference for my Openmaintainer ports are probably more conservative / controlling than those listed already. For any change except comment fixing and rev-bumps due to dependency ABI / API changes, I prefer there to be a PR that I can review before committing. I prefer a PR for even minor version updates that just change the version & checksums (no patches or other tweaks required), but certainly even for missing #include's, adding --disable-werror, or the like.

The reason for my preference is that I'm pretty on top of my ports & I test/verify on (currently) 10.5 PPC through 10.13 Intel (actual hardware; not just a VM; 10.4 PPC & 10.5 Intel coming soon). Hence I'm very likely to find and correct any build issues with my ports (and some others) and provide fixes that work across the various OSXs.

When a release update comes out, I'm notified and try to handle it within 24 hours / I do "devel" updates roughly weekly. Someone else could beat me to the update, in which case there can be conflict and my efforts would be wasted (which I clearly dislike). A PR would allow me to drop what/if I'm doing & use the proposed change, with minimal conflict / waste. Given how easy PRs are in git / Github, I see very little downside.

I heartily agree on the 72 hour timeout for any Openmaintainer port, for a patch or PR where at least 1 other maintainer beyond the OP has verified the change.

Thanks for listening; back to work! - MLD

On Wed, Apr 25, 2018, at 11:33 AM, Ryan Schmidt wrote:
> 
> 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.
> 
>