well, I hope travis-ci will be useful (or we will drop it). as for PR, I meant that it should have been sent to list anyway (but it was not sent for some reason).
I can send using "git send email" as well пн, 6 мая 2019 г. в 11:05, Willy Tarreau <[email protected]>: > Hi Ilya, > > > I made another PR > > > > https://github.com/haproxy/haproxy/pull/92 > > Thank you. > > > (I really like automatic PR to mailing list routing) > > Well, it was the only workable workaround we have when people send PRs. > Sadly we can't block them. Apparently only mirror repositories can block > PRs and github doesn't accept to create them anymore. But when there are > multiple patches in the PR it's not usable as-is anymore, it only serves > as a notification that someone sent something. > > For me, PRs tremendously increase the amount of manipulations, which is > why I tend to postpone them until I think this will not divert me too > much from what I am doing. I just timed the operations on this small > batch and it went from ~15 seconds to review and merge your 4 patches > if they were in mails (just pressing Enter in mutt to review them, > possibly "e" to quickly edit if needed, and "A" to apply), then "g" to > ack the merge, to around 3 minutes to : > - copy the link > - open a browser > - paste the link into the browser's URL bar > - locate the links to the commits in the page > - open each of them in a separate tab > - visit each tab in turn, and for each of them, press Ctrl-L and > append ".patch" at the end of the URL, then press enter > - after the patches are loaded, visit all of them again, to look at the > dates and figure in what order to apply them > - then for each of them : > - review the patch > - Ctrl-S to save the patch > - remember the file name (commit ID) and press Enter > - Alt-tab to switch to the xterm in the development directory > - git am ~/<commit>.patch > - rm -f ~/<commit>.patch > - Alt-tab to switch back to browser again > - Ctrl-W to close the tab > - close browser window > - back to mutt to ack merging and rant about my hate of this workflow > > => This is way longer and more error-prone than the first variant. And > this doesn't even include commenting if I disagree on something, which > additionally requires copy-pasting the relevant parts of the patch > into the response message. There is a reason why most projects > developed on github are so low quality with so horrible commits > and zero maintenance : it encourages laziness and dirtiness. It > costs so much effort to fix minor issues and encourage people to > improve, compared to lazily click on "merge" that you simply think > "bah..." and you merge it as-is, making it impossible to review them > later when trying to make a maintenance version. So you end up with > continuous development made of a pile of junk patches :-/ > > Anyway now I've finally applied your patches. In the future, if you > want to help with a smoother process, please either attach your patches > or use git-send-email. The most efficient workflow is one patch per mail, > like git-send-email does, as it eases reviews (which can also be done by > multiple persons). If you attach them, make sure to use the file names > created by git-format-patch so that there's no doubt when saving files > for manual editing for example. Also it's important to indicate the > intent with a patch or a patch series, i.e. "please merge this", "please > don't merge this, it's just for discussing", "it should be mergeable once > the makefile is fixed", "I think it's OK for merging but I'd prefer an > extra review first", "how about we'd do this", etc. I'm all for being > accommodating with submissions and slightly edit them if needed because > I know that if the work has to be 100% on either side it can total more > time than 90/10 or even 95/5 (but I never edit signed patches beyond > fixing merging issues though). I'm just very careful about the time > spent on my side because I know I'm already a bottleneck, so each extra > minute added here delays everything else. > > Thanks! > Willy >
