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
