i've told you i've tested it and if it breaks things, then you can roll it back.
so far my tests on my own machine, 10.7 and 10.6 are positive. and this isn't about commit messages. really i made all of the changes you asked for. the only one i didn't make were about conditional patches because there are LOTS of conditional patch applications in the LLVM portfile. it's a double standard. simple as that. for me it takes multiple months. for others it takes weeks. what a waste of my time. i'm not investing any more time to get more excuses like the below. but that's fine. hurting your users is what macports is good at (for whatever politically-motivated reasons, like an unnamed sanctimonious perennial untenured ivy league postdoc pushing an agenda to clear funds to eat ramen) hurting your users can come in many ways. unnecessary delays waste of my time. i can't believe i was stupid enough to undertake this. and the creator just sits there doing nothing. he tagged me on trac for nodejs22. i fix it and then he goes missing. sad times. > On Aug 20, 2025, at 8:27 PM, Ryan Carsten Schmidt <[email protected]> > wrote: > > On Aug 20, 2025, at 20:49, Gagan Sidhu via wrote: >> >> why haven't my PRs been merged? > > My previous reviews should not be thought of as exhaustive. I just pointed > out a few issues I saw. There may be other issues. And I don't necessarily > have time to follow up on the feedback I left before but for example I had > pointed out that you're handling os.arch wrong and you haven't fixed that. > > You also said my suggestions were too complicated and you don't care about > the scenarios I raised, but at MacPorts we do care. We advertise features to > users and users might use those features. We want to avoid committing changes > to ports that break those features. Your changes may break cross compiling > for other architectures or OS versions, which are MacPorts features. > > One further issue is that each PR has many commits and they don't follow our > commit message guidelines. > > If each PR represents a single logical change that should be squashed into a > single commit, that's easy and we can squash it in the web interface, > somebody just needs to write the commit message. You know what your changes > do so you're the ideal candidate to write the commit message if you can > follow our guidelines. If they're unclear check our git history to see how > our commit messages are usually written or consult a generic guide on writing > git commit messages. > > But if each PR contains multiple logical changes, then each logical change > should be its own commit with its own commit message. That can be done > locally using "git rebase". > > Thanks, Gagan
