The commend for the vfile_check_signature function in vfile.c, however, says somthing different:

Follow-up: your post hasn't been ignored, but we're been neck deep in other code this week. i've marked your email as to-investigate and will take a look at this by this weekend, at the latest.

The commend for the vfile_check_signature function in vfile.c, however, says somthing different:

This has been corrected in the trunk. Thank you for the report.

Awesome, thank you!

May I remind that I've got another spelling-patch pending ... I'd appreciate it getting in as well

May I remind that I've got another spelling-patch pending ... I'd appreciate it getting in as well

That one i have let sit because, frankly, making that change is a lot of hassle for no functional benefit and arguable style benefit (and i was kinda hoping someone else would make the effort!). Whether or not a dot belongs at the end of a bullet-style-list entry is a matter of taste (and, as the saying goes, there's no accounting for taste). Yes, the help is inconsistent in that regard, but it's not a detail anyone's fretting over and doesn't break anything. Looking at the change history for a couple of those files, even individual contributors have been inconsistent in whether they add a dot or not.

If you will get a contributor agreement printed, signed, and mailed to Richard, we can give you access to apply such patches yourself. Without one on file, we cannot simply apply your patches as-is and are forced to make such changes in a way which does not simply duplicate them. For individual typos and such that's not a real issue, but your reworking of the dots in help text across numerous files is a much larger change. (Such are the headaches involved with software licensing :(.)

Sure, I will sign and mail (may I scan and email?) the contributor agreement.

I myself don’t consider my changes as ones having copyright protection (at least not in my local jurisdiction) – they are simple enough and have no creative aspect to them.

The chanes were following up a more recent set of same changes. I agree they don’t fix anything functional, but I personally consider consistency a value in itself, and thus consistent documentation gives a better impression of the software.

Sure, I will sign and mail (may I scan and email?) the contributor agreement.

Richard requires a physical copy for his records (each copy goes into a fire-proof safe). Whether or not he can accept scanned/email copies in advance of mailed ones, i can't say with certainty.

I myself don’t consider my changes as ones having copyright protection (at least not in my local jurisdiction) – they are simple enough and have no creative aspect to them.

FWIW, i don't, either, but... better safe than sorry. We cannot take any risks with "breaking" the license. It's an unforunate case of "hate the game, not the player."

The chanes were following up a more recent set of same changes. I agree they don’t fix anything functional, but I personally consider consistency a value in itself, and thus consistent documentation gives a better impression of the software.

i'm not saying they're without value, just saying that they're an awful lot of effort for someone to go "independently reproduce" (unless they really want to, of course). The ideal solution is that we get you checkin access (or is that check-in? i'm no longer sure ;)!), then you can apply those changes and make any future ones you like.

The ideal solution is that we get you checkin access (or is that check-in? i'm no longer sure ;)!)

It is check-in 😜

I've sent Richard executed contributor agreement/statement in PDF, and will mail a physical copy, if he asks me to.

Richard requires a physical copy for his records (each copy goes into a fire-proof safe).

A fire-proof safe is actually not enough – my firefighter friends say it also has to be water-proof.

FWIW, i don't, either, but... better safe than sorry. We cannot take any risks with "breaking" the license. It's an unforunate case of "hate the game, not the player."

I have no problems signing such a statement.

i'm not saying they're without value, just saying that they're an awful lot of effort for someone to go "independently reproduce" (unless they really want to, of course).

Actually not that particular patch – the only mental effort required was asking myself a question of whether a particular sentence was long enough for period to end it.

The ideal solution is that we get you checkin access (or is that check-in? i'm no longer sure ;)!), then you can apply those changes and make any future ones you like.

So I'd put them on a separate branch, which I could use for such documentation fixes? That would be awesome!

As discussed, I put --help spelling changes in trunk. Thanks!