From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org, Phillip Lord <phillip.lord@russet.org.uk>
Subject: Re: Development suggestions from an ENSIME developer
Date: Fri, 22 Jul 2016 09:35:41 -0400 [thread overview]
Message-ID: <jwvfur1akb5.fsf-monnier+Inbox@gnu.org> (raw)
In-Reply-To: <83d1m6xint.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 22 Jul 2016 09:59:18 +0300")
> The number of manual actions one needs to do when processing a patch
> can be counted, and the counts can be compared. The "normal" speed of
> each operation can also be measured. So I see no issues of coming up
> with a more-or-less objective assessment of the proposed workflow vs
> the existing one.
I think in the best-case scenario, a merge-request system won't help
very much
1a- You look at the patch in your email
1b- You look at the patch in your the MRS
2a- You think it looks good
2b- You think it looks good
3a- You M-| it to "git am; git push"
3b- You accept the request
But in my experience, step "3a" all too often doesn't work out so
nicely, because the patch is not quite in the right format. With some
luck it's been word-wrapped or worse. In practice I find "3a" to be
surprisingly time-consuming. The merge-request flow avoids
those pitfalls.
Also, the "1a" step can be fairly different from "1b" because the tool
knows it's a patch, it knows against which branch in which repository it
applies, etc... so "1a" can precompute specialized extra info, such as:
- the result of a tentative build (compilation warnings and regression
tests, tho that depends on having such a system setup and having the
resources to run it for every merge-request (and every update of it)).
- a diff w.r.t the previous version of that same merge request.
- info about the fact that the patch doesn't apply against "master"
any more.
- hopefully/ideally the tool could have already checked copyright.list
for you.
- ...
Depending on the actual tool you end up using and other considerations,
an MRS can also offer further advantages (don't know enough about
Kallithea nor Gitlab to know if they offer those features):
- "3b" can just mark the request as "reviewed by <foo>", so you can give
"half-commit" rights to some users.
- it sometimes makes it easier for 3rd parties (or for the reviewer) to
update the merge request directly (instead of adding comments).
Of course, there's also the effect on the side of the patch-submitters,
where the precise flow is often made easier for them because there's no
doubt about where to send the patch, in which format, etc...
Stefan
next prev parent reply other threads:[~2016-07-22 13:35 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-20 13:54 Development suggestions from an ENSIME developer Lars Ingebrigtsen
2016-07-20 14:02 ` Clément Pit--Claudel
2016-07-22 22:48 ` Robert Cochran
2016-07-23 7:30 ` Eli Zaretskii
2016-07-23 9:00 ` Lars Ingebrigtsen
2016-07-23 19:52 ` Richard Stallman
2016-07-23 13:50 ` Clément Pit--Claudel
2016-07-23 20:14 ` Phillip Lord
2016-07-25 18:34 ` Robert Cochran
2016-08-03 6:05 ` John Wiegley
2016-08-06 18:42 ` Alex Dunn
2016-07-20 14:03 ` Dmitry Gutov
2016-07-20 14:08 ` Lars Ingebrigtsen
2016-07-20 14:12 ` Dmitry Gutov
2016-07-20 14:23 ` Christian Kruse
2016-07-20 14:41 ` Dmitry Gutov
2016-07-20 14:30 ` Christian Kruse
2016-07-20 14:44 ` Lars Ingebrigtsen
2016-07-20 15:02 ` Clément Pit--Claudel
2016-07-20 15:07 ` Lars Ingebrigtsen
2016-07-20 15:31 ` Clément Pit--Claudel
2016-07-20 17:00 ` Stefan Monnier
2016-07-21 18:40 ` Phillip Lord
2016-07-21 19:30 ` Eli Zaretskii
2016-07-21 20:22 ` Stefan Monnier
2016-07-21 21:26 ` Christian Kruse
2016-07-21 22:04 ` Dmitry Gutov
2016-07-21 20:23 ` Phillip Lord
2016-07-21 20:50 ` joakim
2016-07-22 6:59 ` Eli Zaretskii
2016-07-22 10:46 ` Lars Ingebrigtsen
2016-07-22 11:48 ` Lars Ingebrigtsen
2016-07-22 13:00 ` Robert Weiner
2016-07-22 13:34 ` Eli Zaretskii
2016-07-22 14:28 ` Robert Weiner
2016-07-22 14:45 ` Ted Zlatanov
2016-07-22 13:35 ` Stefan Monnier [this message]
2016-07-22 14:38 ` Eli Zaretskii
2016-07-22 14:56 ` Stefan Monnier
2016-07-22 15:58 ` Phillip Lord
2016-07-22 15:47 ` Phillip Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvfur1akb5.fsf-monnier+Inbox@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=phillip.lord@russet.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.