Don't merge, just testing online Github editing to see if it creates a branch on Geany repo and triggers a commit mail. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2035
-- Commit Summary --
* Add Matthew Brush to COMMITTERS
-- File Changes --
M COMMITTERS (1)
-- Patch Links --
https://github.com/geany/geany/pull/2035.patch https://github.com/geany/geany/pull/2035.diff
Closed #2035.
No commit mail or branch created, closing.
@codebrainz thats because you edited `codebrainz:` not `geany:`. You get commit emails & IRCs because our bot is not smart enough to distinguish commits to master from commits to branches.
Yeah, I thought that was the normal way of doing the online editing. I do want commit mails on Geany repo branch commits, just not for random PRs.
@codebrainz just tell @elextr not to online-PR from the Geany repo ;)
@b4n and @codebrainz ...
Contributions to Geany are so minimal that putting artificial restrictions and rules in place for how to do it is the wrong way to go. Instead everyone should be encouraged to contribute PRs by any means available. Github provides easy tools, encourage their use.
If it gets contributions then using the Github online editing should be __actively__ encouraged. Its not going to get merged until its reviewed and tested, so what does it matter how its contributed.
Geany has traditionally not been a leet project, but an open and friendly one, insisting on the "one true way" to contribute isn't encouraging participation. If I'm short of time (which is always) there are two ways, either I will use the quickest easiest way, or I won't contribute. `</rant>`
@codebrainz thats because you edited `codebrainz:` not `geany:`. You get commit emails & IRCs because our bot is not smart enough to distinguish commits to master from commits to branches.
"not smart enough" is by design in this case. Commit mails and IRC messages are sent for any push in the Geany (and G-P as well) repository. This also includes any branches besides `master`. In this case, the branch was `elextr-patch-4` of Lex simple change but this is also true for sub release branches like the current `1.34` branch.
IMO it is good to have commit mails also for branches besides master.
Apart from that, I completely support what Lex said above about minimizing restrictions for contributions.
@elextr agreed, I don't blame it, and don't particularly care for those commit emails. I just wish it could automatically do that on the contributor's fork (or fork it automatically if need be) rather than on the main repo so things would be cleaner, but it's not a problem.
The problem last time was just me not reviewing/testing properly :grin:
To be clear, I'm not really opposed to using Github to make edits+PRs[0], I just wanted to see how it worked because I hadn't tried it before and it seemed odd that Github was messing with the main repo in order to make PRs. Now I realize it lets people with push access edit+PR directly on the main repo and doesn't force you to do it on your own fork, which is the only part I don't like much.
[0]: for small text/documentation changes. I do think PRers should at least test code changes themselves on their machine as a minimum bar though (which _was_ done last time), at which point it's no faster re-doing the changes in the online editor instead of just pushing to your fork and making a PR. From this point of view, the online editor isn't terribly useful, IMO.
For small text/documentation changes I totally disagree, if someone wants to make a few word changes to make docs clearer why force them to install some obscure document processing system just to make a PR.
Thats what I mean by putting artificial restrictions in their way. Its the job of Travis and the nightlys to check they don't do something that breaks the build.
@codebrainz oh, there is a full stop after "changes" in your footnote, I read it as one sentence. We are in vociferous agreement then :)
github-comments@lists.geany.org