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 <w...@1wt.eu>:

> 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

Reply via email to