Require c99 language support or newer

[jonesmz]

Note also that gcc 5.4.0 and later default to the gnu11 version of the C11 standard.

[jnpkrn]

Good point. I think we are shooting for C99 at minimum.

[chrissie-c]

yes, good idea. Thanks!

[jnpkrn]

@jonesmz Perhaps one point for the future: it would be strongly preferred
if you could have your account (or workflow -- have you edited on-the-fly
via GitHub interface?) associated with proper email address, for some kind
of persistent/reliable mapping of your libqb contributions to your persona.

At least @users.noreply.github.com intermediary type of contact does not
fit that definition in my book, however I look at it.

[jnpkrn]

@jonesmz Sorry, it must be some new misfeature of GitHub, I can observe
the same at my own recent contribution as well!

[jnpkrn]

Actually, it was due to the change of project settings.
My proposal is to resort to manual handling of the PRs going forward.
It's a matter of two git commands or so, after all.

Web interface machinery for PR handling is overboard intrusive.

[jonesmz]

@jnpkrn

Sorry, no, not interested in changing that setting. I actually have my "real" email set up for my git command line interface, but only because "jonesmz@randomcomputername" was silly.

Now that I know github is auto-hiding it, I much prefer not revealing my personal email to the world perpetually. I get enough spam as it is.

Contrasted against you ([email protected] , correct?), I am not paid to work on open source by my employer, so I have no incentive to continue participating perpetually.

[jnpkrn]

On 18/05/17 09:00 -0700, jonesmz wrote: Sorry, no, not interested in changing that setting. I actually have my "real" email set up for my git command line interface, but only because ***@***.***" was silly.

Please accept my apologies once more, I had no clue what was causing that utter-nonsense obfuscation in the git tree itself originally (oh, the PR acceptance process for the project has changed without warning), and I understand your concerns -- I am actually in the same boat as you (if the web interface can hide the address, why not, the "real thing" is the tree itself, right?) with privacy of the email address (I don't mind the truth be captured in the tree, though, better than GH proxy addressing for sure in my view). I think the takeaway for us is, if we want to avoid merge commits at any cost (I was told this was the main motivation, and yes, they are not nice, but one can filter them out with `--no-merges` option to most of the relevant git commands) is to do the old good manual fast-forward merging as mentioned. Thanks for your contribution (and bearing with me responding to the changed rules of the game, ehich has nothing to do with the players themselves).

…

-- Jan (Poki)