Re: Re: More classes of maintainer (was: Re: branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms)

On 11/1/23 at 9:02 PM, Eric Gallager wrote: > I think if we add a separate "interested party" role, it would > probably be good to change the abandonment procedure so that instead > of removing unresponsive maintainers entirely, they'd just get moved > to the "interested party" role instead.

Re: More classes of maintainer (was: Re: branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms)

On Wed, Nov 1, 2023 at 9:54 PM Joshua Root wrote: > > On 2/11/2023 12:32, Perry E. Metzger wrote: > > As an aside, as it stands, the rules situation with closed maintainer / > > open maintainer is kind of unpleasant already. For example, I'd like to > > be able to indicate that I'm happy with

More classes of maintainer (was: Re: branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms)

On 2/11/2023 12:32, Perry E. Metzger wrote: As an aside, as it stands, the rules situation with closed maintainer / open maintainer is kind of unpleasant already. For example, I'd like to be able to indicate that I'm happy with anyone making reasonable changes to my ports on their own without

Re: [macports-ports] branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms

As an aside, as it stands, the rules situation with closed maintainer / open maintainer is kind of unpleasant already. For example, I'd like to be able to indicate that I'm happy with anyone making reasonable changes to my ports on their own without waiting three days for me, but there's no

Re: [macports-ports] branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms

An understandable presumption in itself, however there was another force push after dluke's last comment, so the changes that ended up being merged had not been reviewed by the maintainer. This was pretty clearly just a misunderstanding, but maybe we should clarify the policies to only allow

Re: [macports-ports] branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms

Your communication in the thread was: > ideally we'll get confirmation from @barracuda156 that we've got a working solution before we merge as well. After he verified that it was working for him, I presumed you were okay with it being committed. Perry On

Re: [macports-ports] branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms

Perry - I had not yet signed off on this PR. The port is not openmaintainer. Please refrain from making changes to non-openmaintainer ports without the maintainer's approval. > On Nov 1, 2023, at 12:48 PM, Christopher Chavez via macports-changes > wrote: > Perry E. Metzger (pmetzger) pushed

llvm-3.3/3.4 broken for ppc64, leaving ld64-97 broken

This is forever broken, which means that nothing can be built on Leopard for ppc64 in default Macports setup: https://trac.macports.org/ticket/68614 Linker requires llvm-3.3 (or llvm-3.4, optionally), neither builds for ppc64. While cctools have dropped requirement for depending on llvm, it is