Upgrade port:QtCurve, fixing QtCurve-qt5

[RJVB (René Bertin)]

port:QtCurve-qt5 is still shipping an older version which fails to build against Qt 5.9 and newer. Attached is an update which provides the latest upstream QtCurve version as well as the current upstream port implementation from my macstrop repo.

Patchfiles and other resources are in the tarball.

[RJVB (René Bertin)]

Replying to mf2k:

It's both... the main reason to update was to fix a defect...

[pmetzger (Perry E. Metzger)]

Howdy! Do you think you could redo this as a github pull request? It will be acted on faster that way.

[pmetzger (Perry E. Metzger)]

In 6b1fe110a0a558d323ebc8b62ca8fb9938d824c1/macports-ports (master):

qtcurve: update to 1.9.0

Submitted by maintainer (RJVB)
Also fixes QtCurve-qt5
Closes: #56039

[pmetzger (Perry E. Metzger)]

I committed this manually, but just as a note: it is a lot less work for other people if you commit your updates directly or submit github pull requests.

[RJVB (René Bertin)]

I know. I'd love to be able to commit changes directly; pull requests are a lot more time-consuming for me so I avoid them (shouldn't take away all reasons to get commit permission, right? ;) ).

I can of course attach monolithic diffs for all changes to the entire port directory, in the future.

[pmetzger (Perry E. Metzger)]

Pull requests are just about as easy in GitHub as directly committing your own. You just...

1. Fork the repo
2. Check out a new branch for your changes.
3. Commit your changes and push up the branch to github.
4. Click on the button to request a pull.

I'm happy to help you with your first couple to get you into the swing of it.

[pmetzger (Perry E. Metzger)]

BTW, a monolithic diff wouldn't have helped. The real issue is the lack of things like the CI system or the ability to do code review here. GitHub is vastly superior. If there's just one line you should change, I can click on the line in the diff, attach comments, and even track whether you've pushed a fix for that line without any effort. It's so much cleaner.

[RJVB (René Bertin)]

I know exactly how github PRs work, they're about the worst patch review mechanisms I've seen. (And such things are are in principle not necessary for upgrades to one's own ports.)

[pmetzger (Perry E. Metzger)]

I strongly disagree. The code review mechanisms in GitHub, though imperfect, are pretty good, and are vastly better than what we have in Trac, which is no system for such things at all. Trac offers no continuous integration or test mechanisms either.

Anyway, for good or ill, MacPorts now uses GitHub for much of its work.

Note that I happen to loathe Git (compared to things like Mercurial it's much less nice) but it's what the tools are now written for and we're kind of stuck with the world we have rather than the one we wished we lived in. So, if you want to get your stuff looked at with reasonable speed, please submit via PRs.

[RJVB (René Bertin)]

You can disagree all you like with PRs being "about the worst patch review mechanisms I've seen" if you think that means anything without actually having looked through my eyes ...

Note that I happen to loathe Git (compared to things like Mercurial it's much less nice)

IIRC Mercurial is even slower and/or has an even larger footprint on disk, or maybe that was bazaar.

Also note that I have often toyed with the idea of creating a true fork of the ports tree that contains my ports and portgroups. In practice I don't want to have to maintain one or more copies of that huge ports repo (in addition to spending my time applying each and every update), so I have stuck with my macstrop tree with instructions how to "install" it.

we're kind of stuck with the world we have rather than the one we wished we lived in.

Indeed, good thing I'm never in a hurry O:-) (and sadly the co-maintainer I used to have who took care of commits and PRs is no longer stuck in this world).