RE: Commit Messages
> From: Fred Wright > Date: 2023-07-15 18:57:46 > > In recent times, commit messages failing to conform to the guidelines have > been becoming more common - specifically, the failure to include a blank line > after the summary. The guidelines even state briefly why this matters, though > perhaps not emphatically enough. Recent offenders are: > > 2d9585490dc87249c189c211a228984b3a3830c7 > 331c484f0c10d378bcbf011fa14cb7fc0e1768be > f5ce144934601cc243df6e02b2d47b7956acd335 > b395f71013212e625fb96051bcc9a31aa0b5bd26 > > The standard git tools split a commit message into a summary (a.k.a. subject) > and a body, with the first blank line being the division point. In format > strings, these are %s and %b, respectively. Some third-party git tools limit > the summary to the first line, so people using such tools may not even notice > the error, but such tools shouldn't be the standard. The output of commands > like "git log --oneline" and "git branch -v" becomes quite annoying with this > error. Sorry folks, completely forgot about the Git convention regarding a blank line. I shall endeavor to include said line separator, in future commits. As for enforcing this via a pre-commit hook, sounds good to me.
Re: Commit Messages
There are Actions usable on GitHub which can mark PRs as failing if they do not match certain quality constraints. I have not used any of these, but these are ones that are explicitly not using the conventional commits format: - https://github.com/GsActions/commit-message-checker: the most flexible, regex-based - https://github.com/mristin/opinionated-commit-message: opinionated - https://github.com/platisd/bad-commit-message-blocker: uses Python NLP to check for imperative subjects -a On Sun, Jul 16, 2023 at 12:13 AM Fred Wright wrote: > > On Sat, 15 Jul 2023, David Gilman wrote: > > > I imagine this can be linted in the git local commit-msg hook. It > > won't stop a dedicated offender who can push directly to master but it > > wouldn't hurt to ship it in the macports-ports repo and promote it in > > the guidelines. > > It would be fairly straightforward to catch this in a pre-commit hook, and > those apply at the time commits are created, and hence don't care about > whether the commits will eventually be pushed directly or submitted as > PRs. But hooks don't propagate across repos, so such a hook would only > apply to users who'd explicitly installed it. > > Another possibility would be a receiver-side hook on GitHub, but those > aren't intended for this sort of purpose, so constructing such a hook > would be more complicated. > > Fred Wright > > > On Sat, Jul 15, 2023 at 2:58 PM Fred Wright wrote: > >> > >> > >> In recent times, commit messages failing to conform to the guidelines > have > >> been becoming more common - specifically, the failure to include a blank > >> line after the summary. The guidelines even state briefly why this > >> matters, though perhaps not emphatically enough. Recent offenders are: > >> > >> 2d9585490dc87249c189c211a228984b3a3830c7 > >> 331c484f0c10d378bcbf011fa14cb7fc0e1768be > >> f5ce144934601cc243df6e02b2d47b7956acd335 > >> b395f71013212e625fb96051bcc9a31aa0b5bd26 > >> > >> The standard git tools split a commit message into a summary (a.k.a. > >> subject) and a body, with the first blank line being the division point. > >> In format strings, these are %s and %b, respectively. Some third-party > >> git tools limit the summary to the first line, so people using such > tools > >> may not even notice the error, but such tools shouldn't be the standard. > >> The output of commands like "git log --oneline" and "git branch -v" > >> becomes quite annoying with this error. > >> > >> Fred Wright > > > > > > > > -- > > David Gilman > > :DG< > > > > -- Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca http://www.halostatue.ca/ • http://twitter.com/halostatue
SDL2 for older systems: which components we need enabled? Cocoa vs X11
libsdl 2.0.22 (our Snow Leopard port) builds on PowerPC with unoffensive fixes, however I had to disable cocoa video and joystick for that. They are likely fixable (though no idea whether and how they gonna work), but at least cocoa video gonna require a massive rewrite – or perhaps falling back to an earlier implementation. (Well, this is not a kind of code I can genuinely rewrite – only adapt patches and maybe improve something a bit.) However, if X11 implementation is a meaningful replacement, it builds fine with no trickery. Any thoughts? P. S. ICE on hidapi is trivially fixable – I just reverted a commit which has broken that. After that, hidapi builds fine.
Re: SDL2 for older systems: which components we need enabled? Cocoa vs X11
As far as I know, we don't have any ports that use SDL2 via X11/Xquartz. All the ports use the Cocoa interface. The modifications that were made to SDL2 by miniupnp to run on Tiger and Leopard were fairly extensive, to an older version of SDL2, but they worked to allow a number of ports that required libsdl2 to work on those systems. I have those mods tucked away in the archives of the TigerPorts and LeopardPorts repos. Any newer version of libsdl2/SDL2 was not able to be adjusted to be useful on those older systems. We did have one newer version that would build, but was so broken by the hacks needed to make it build that it was useless in practical use. Which brings me to the next point. It is quite possible to make hacks/patches to software that will allow it to build -- at an extreme, you and #if 0 / #endif out that entire source, and it will compile just fine. But especially for things like SDL2, what is needed is more than that -- you have to see if software built against such patched versions will actually work, and this sometimes takes some fairly extensive testing to see what the warts might be. Ken > On Jul 19, 2023, at 8:32 AM, Sergey Fedorov wrote: > > libsdl 2.0.22 (our Snow Leopard port) builds on PowerPC with unoffensive > fixes, however I had to disable cocoa video and joystick for that. > They are likely fixable (though no idea whether and how they gonna work), but > at least cocoa video gonna require a massive rewrite – or perhaps falling > back to an earlier implementation. (Well, this is not a kind of code I can > genuinely rewrite – only adapt patches and maybe improve something a bit.) > > However, if X11 implementation is a meaningful replacement, it builds fine > with no trickery. > > Any thoughts? > > P. S. ICE on hidapi is trivially fixable – I just reverted a commit which has > broken that. After that, hidapi builds fine.
