Development suggestions from an ENSIME developer

Development suggestions from an ENSIME developer

[Lars Ingebrigtsen]

An open letter was posted on dar interwebs

https://medium.com/@fommil/open-letter-to-the-emacs-maintainers-226cb67a961f#.1pq4ienoh

and discussion predictably followed on the "code of conduct" thing on
Hacker News:

https://news.ycombinator.com/item?id=12125057

I'm just posting the link here because I found it mildly interesting,
although I don't really find any of the technical suggestions to be
very...  er...  convincing.  Your mileage may vary.

And as for the "code of conduct" thing, I'm confident that assholish
behaviour isn't tolerated here, so I don't really think that's
necessary, either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Development suggestions from an ENSIME developer

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 442 bytes --]

On 2016-07-20 09:54, Lars Ingebrigtsen wrote:
> And as for the "code of conduct" thing, I'm confident that assholish
> behaviour isn't tolerated here, so I don't really think that's
> necessary, either.

I for one would welcome a code of conduct :) These things tend to send an explicit positive message, and there are virtually no downsides to having one.
LibrePlanet, Mailman, and GNU Health already seem to have one.

Clément. 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Development suggestions from an ENSIME developer

[Dmitry Gutov]

On 07/20/2016 04:54 PM, Lars Ingebrigtsen wrote:

> I'm just posting the link here because I found it mildly interesting,
> although I don't really find any of the technical suggestions to be
> very...  er...  convincing.  Your mileage may vary.

A migration to gitlab.com (or a self-hosted instance of Gitlab) sounds 
pretty attractive. We'd get a modern-ish issue tracker with it, as well 
as a code review tool and VCS browser.

Re: Development suggestions from an ENSIME developer

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> A migration to gitlab.com (or a self-hosted instance of Gitlab) sounds
> pretty attractive. We'd get a modern-ish issue tracker with it, as
> well as a code review tool and VCS browser.

Having the VCS browser in Emacs is much more convenient than struggling
with a web interface, I think.

Anything that takes us out of Emacs is a less than optimal.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Development suggestions from an ENSIME developer

[Dmitry Gutov]

On 07/20/2016 05:08 PM, Lars Ingebrigtsen wrote:

> Having the VCS browser in Emacs is much more convenient than struggling
> with a web interface, I think.

One doesn't take from the other. Different users have different 
preferences on this.

For me, it's often easier to look at a different branch in the browser, 
rather than have to check it out locally.

Anyway, I agree that a VCS browser is the least important tool of the three.

Re: Development suggestions from an ENSIME developer

[Christian Kruse]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]


Dmitry Gutov <dgutov@yandex.ru> writes:

> For me, it's often easier to look at a different branch in the browser, 
> rather than have to check it out locally.

Are you aware that you a) don't need to check out the branch to have a
look at it (e.g. git log <branch> works well, git show <hash> works on
every commit, etc, pp) and b) you can do everything with magit pretty
well?

I don't want to disregard your workflow, just trying to praise git and
magit features :-)

Best regards,
-- 
Christian Kruse
https://wwwtech.de/about

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Development suggestions from an ENSIME developer

[Christian Kruse]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]


Lars Ingebrigtsen <larsi@gnus.org> writes:

> An open letter was posted on dar interwebs
>
> https://medium.com/@fommil/open-letter-to-the-emacs-maintainers-226cb67a961f#.1pq4ienoh

While I disagree on a lot of the premises (e.g. the email/mailing list
thing - most of the developers I know are pretty happy with email and
lists) I think he has a point: it is *very* hard to get into Emacs
coding. I tried it more than once but failed. Documentation seems very
distributed (for a look here, for b look over there, ...), a clear
step-by-step guide to get a build environment including running tests
seems to be missing. E.g. why is there no "contribute" document on the
shiny new website? Heck, I even failed to find beginner bugs in the bug
tracker.

Don't get me wrong, I don't want to by grumpy, I am extremly grateful
for the hard work you people do.

Best regards,
-- 
Christian Kruse
https://wwwtech.de/about

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Development suggestions from an ENSIME developer

[Dmitry Gutov]

On 07/20/2016 05:23 PM, Christian Kruse wrote:

> Are you aware that you a) don't need to check out the branch to have a
> look at it (e.g. git log <branch> works well, git show <hash> works on
> every commit, etc, pp) and b) you can do everything with magit pretty
> well?

Sure, but you can't do that with Emacs's built-in features (yet?), and I 
don't use Magit myself.

With a VCS browser, it's also easier to show a branch or a commit to 
someone else: just copy an URL and email/message it.

Re: Development suggestions from an ENSIME developer

[Lars Ingebrigtsen]

Christian Kruse <cjk@defunct.ch> writes:

> I think he has a point: it is *very* hard to get into Emacs
> coding. I tried it more than once but failed. Documentation seems very
> distributed (for a look here, for b look over there, ...), a clear
> step-by-step guide to get a build environment including running tests
> seems to be missing. E.g. why is there no "contribute" document on the
> shiny new website?

Yeah, I agree that the documentation for getting started is rather
distributed.  And the recipe (on GNU/Linux systems) is so trivial.

It would be nice to have it emphasised just how easy it is somewhere
central, like:

----
Cut and paste these five lines and you have a complete working Emacs
that you can hack and send patches to:

sudo apt-get build-dep emacs24
git clone git://git.savannah.gnu.org/emacs.git
cd emacs
make
./src/emacs &

Send patches via `M-x report-emacs-bug'.  Happy hacking!
----

Of course, if you want to make larger changes then you have to know
about ChangeLog formats and assignments and testing and etc etc etc, but
for people starting out, hacking on and contributing to Emacs is so easy
it's kinda difficult to believe, which is perhaps why people imagine it
to be difficult.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Development suggestions from an ENSIME developer

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 352 bytes --]

On 2016-07-20 10:44, Lars Ingebrigtsen wrote:
> Send patches via `M-x report-emacs-bug'.  Happy hacking!

That part could be made a bit better; not everyone (even experienced users) has set up Emacs to send email.
Maybe the text in report-emacs-bug could mention how to open the resulting report in the system's default mail client?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Development suggestions from an ENSIME developer

[Lars Ingebrigtsen]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> That part could be made a bit better; not everyone (even experienced
> users) has set up Emacs to send email.
> Maybe the text in report-emacs-bug could mention how to open the
> resulting report in the system's default mail client?

When you try to send email from `M-x report-emacs-bug' (in an
unconfigured Emacs), it'll take you through the process.  So no
explanation is necessary.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Development suggestions from an ENSIME developer

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 551 bytes --]

On 2016-07-20 11:07, Lars Ingebrigtsen wrote:
> Clément Pit--Claudel <clement.pit@gmail.com> writes:
>> That part could be made a bit better; not everyone (even experienced
>> users) has set up Emacs to send email.
>> Maybe the text in report-emacs-bug could mention how to open the
>> resulting report in the system's default mail client?
> 
> When you try to send email from `M-x report-emacs-bug' (in an
> unconfigured Emacs), it'll take you through the process.  So no
> explanation is necessary.

Hmm. How did I miss that? Thanks!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Development suggestions from an ENSIME developer

[Stefan Monnier]

> I'm just posting the link here because I found it mildly interesting,
> although I don't really find any of the technical suggestions to be
> very...  er...  convincing.  Your mileage may vary.

I'd be really happy to have some kind of system that can manage a queue
of pull-requests.  Even better if I can manage it when I'm not online.


        Stefan

Re: Development suggestions from an ENSIME developer

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm just posting the link here because I found it mildly interesting,
>> although I don't really find any of the technical suggestions to be
>> very...  er...  convincing.  Your mileage may vary.
>
> I'd be really happy to have some kind of system that can manage a queue
> of pull-requests.  Even better if I can manage it when I'm not online.


I'm willing to put a little work into scoping the alternatives. As a
relatively new contributor, I think, this would be a change that would
significantly help. It's just much easier to track what is being said
wrt a PR than passing patches around.

There needs to be the willingness to adopt it, if we choose something,
though. If this is clear, I think, we might be able to get some others
to help in the process.

Phil

Re: Development suggestions from an ENSIME developer

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Thu, 21 Jul 2016 19:40:24 +0100
> Cc: emacs-devel@gnu.org
> 
> There needs to be the willingness to adopt it, if we choose something,
> though.

Expect it to be adopted if it makes our jobs simpler, like faster, or
saves us from doing some of the stuff at all.  Otherwise, you will
have difficulty convincing at least me to move.

Also, I think the solution should support text-mode browsers, such as
Lynx or Emacs's eww on TTY frames.  IOW, anything that requires GUI
and won't work otherwise is probably out of question to begin with.
(This requirement is not for me personally.)

Re: Development suggestions from an ENSIME developer

[Stefan Monnier]

> Expect it to be adopted if it makes our jobs simpler, like faster, or
> saves us from doing some of the stuff at all.  Otherwise, you will
> have difficulty convincing at least me to move.

> Also, I think the solution should support text-mode browsers, such as
> Lynx or Emacs's eww on TTY frames.  IOW, anything that requires GUI
> and won't work otherwise is probably out of question to begin with.
> (This requirement is not for me personally.)

Hopefully a pull-request can appear as a Git branch, so the maintainer
who can't or doesn't want to use a browser can use "git diff/merge" and
such to view and accept a pull-request.

To review/comment on a pull-request, you'll need something else, and
typically this is a web UI.  Most/all of those are pretty much unusable in
something like eww/lynx.  But there's a good chance someone can code up
an ad-hoc Emacs interface to the system (something like sx.el).


        Stefan

Re: Development suggestions from an ENSIME developer

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Date: Thu, 21 Jul 2016 19:40:24 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> There needs to be the willingness to adopt it, if we choose something,
>> though.
>
> Expect it to be adopted if it makes our jobs simpler, like faster, or
> saves us from doing some of the stuff at all.  Otherwise, you will
> have difficulty convincing at least me to move.

*shrugs*

As with everything, it will makes things somewhat slower during
adoption. And I can only give you anecdotal evidence that it will make
things better after adoption.


> Also, I think the solution should support text-mode browsers, such as
> Lynx or Emacs's eww on TTY frames.  IOW, anything that requires GUI
> and won't work otherwise is probably out of question to begin with.
> (This requirement is not for me personally.)

If that is a hard requirement, then I think we are not going to get much
further with a web 2.0 program. The best option is going to be somewhere
to host clones for developers, and then use debbugs.

But, it really is a hard requirement.

Phil

Re: Development suggestions from an ENSIME developer

[joakim]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: phillip.lord@russet.org.uk (Phillip Lord)
>>> Date: Thu, 21 Jul 2016 19:40:24 +0100
>>> Cc: emacs-devel@gnu.org
>>> 
>>> There needs to be the willingness to adopt it, if we choose something,
>>> though.
>>
>> Expect it to be adopted if it makes our jobs simpler, like faster, or
>> saves us from doing some of the stuff at all.  Otherwise, you will
>> have difficulty convincing at least me to move.
>
> *shrugs*
>
> As with everything, it will makes things somewhat slower during
> adoption. And I can only give you anecdotal evidence that it will make
> things better after adoption.
>
>
>> Also, I think the solution should support text-mode browsers, such as
>> Lynx or Emacs's eww on TTY frames.  IOW, anything that requires GUI
>> and won't work otherwise is probably out of question to begin with.
>> (This requirement is not for me personally.)
>
> If that is a hard requirement, then I think we are not going to get much
> further with a web 2.0 program. The best option is going to be somewhere
> to host clones for developers, and then use debbugs.

Gitlab has a cli-interface, so you can do things with it from a shell.

(FWIW I'm not doing any advocating here, I'm just helping to provide
info.)

I have set up gitlab instances for clients, and its not hard to do using
docker-compose.

I don't find the gitlab bug tracker spectacular, but it's not designed
to be either, AFAICT. 

> But, it really is a hard requirement.
>
> Phil
>

-- 
Joakim Verona

Re: Development suggestions from an ENSIME developer

[Christian Kruse]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]


Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Hopefully a pull-request can appear as a Git branch, so the maintainer
> who can't or doesn't want to use a browser can use "git diff/merge" and
> such to view and accept a pull-request.

Pull requests are just sugar around remotes. So to use `git diff` et all
you need to add a new remote and fetch it; as soon as this is done you
can work with git on it as usual:

git remote add foo ssh://foo/bar
git fetch foo
git diff master foo/master`


Best regards,
-- 
Christian Kruse
https://wwwtech.de/about

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Development suggestions from an ENSIME developer

[Dmitry Gutov]

On 07/21/2016 11:22 PM, Stefan Monnier wrote:

>> Also, I think the solution should support text-mode browsers, such as
>> Lynx or Emacs's eww on TTY frames.  IOW, anything that requires GUI
>> and won't work otherwise is probably out of question to begin with.
>> (This requirement is not for me personally.)
>
> Hopefully a pull-request can appear as a Git branch, so the maintainer
> who can't or doesn't want to use a browser can use "git diff/merge" and
> such to view and accept a pull-request.

There is always a branch associated with the request, yes. And also, 
when you merge the branch using the command line and push, that closes 
the pull/merge request automatically.

(BTW, in Gitlab parlance these are called "merge requests", not "pull 
requests", since, unlike on Github, the branch-to-merge is always in the 
same repository).

> To review/comment on a pull-request, you'll need something else, and
> typically this is a web UI.  Most/all of those are pretty much unusable in
> something like eww/lynx.  But there's a good chance someone can code up
> an ad-hoc Emacs interface to the system (something like sx.el).

A brief search of existing projects points to 
https://github.com/nlamirault/emacs-gitlab.

It doesn't seem to support commenting on pull requests so far, though, 
and we might have to add a "standard" UI instead of ones using Helm or Ivy.

Re: Development suggestions from an ENSIME developer

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Thu, 21 Jul 2016 21:23:28 +0100
> 
> > Expect it to be adopted if it makes our jobs simpler, like faster, or
> > saves us from doing some of the stuff at all.  Otherwise, you will
> > have difficulty convincing at least me to move.
> 
> *shrugs*
> 
> As with everything, it will makes things somewhat slower during
> adoption.

That's for sure, but I wasn't talking about the transition period.

> And I can only give you anecdotal evidence that it will make things
> better after adoption.

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.

My problem is with having to learn a new system just because it's
considered (or even is) "newer" or "more shiny" or presents a prettier
graphics than the old one.  These alone are IMO not enough to justify
the effort of learning yet another tool.

> > Also, I think the solution should support text-mode browsers, such as
> > Lynx or Emacs's eww on TTY frames.  IOW, anything that requires GUI
> > and won't work otherwise is probably out of question to begin with.
> > (This requirement is not for me personally.)
> 
> If that is a hard requirement, then I think we are not going to get much
> further with a web 2.0 program. The best option is going to be somewhere
> to host clones for developers, and then use debbugs.
> 
> But, it really is a hard requirement.

I don't know if this is a hard requirement, it isn't mine.  I don't
use Lynx.  I do use Emacs on a TTY, for remotely accessing other
machines, and I do sometimes need to be able to fix bugs and commit
changes from such a remote session.  So a solution that can be
reasonably used from a TTY frame in Emacs or from a shell prompt will
be welcome.

Also, if a Web interface is really required for all the proposed
alternatives, then it means I'll have to leave Emacs and fire up a Web
browser, right?  Because EWW, as good as it is (and it is good), is
still not up to that level, is it?

Re: Development suggestions from an ENSIME developer

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> 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.

Yup.

The system we have in use today for bug reports is a push-based one:
People use `M-x report-emacs-bug' and it lands in our email (or on
Gmane) and we (I mean Eli :-)) read{s,} it and respond{s,} to it, often
closing it within one or two interactions.

There are other, longer interactions (involving much code review and
back-and-forth discussion), of course, but these are not the typical
ones.

I'm all for having new and shiny and good systems for dealing with these
complex interactions, but if this new and shiny systems involves
pressing reload on a web page a lot, and tooling around with checkboxes
and editing stuff in a web browser even for the trivial bug reports (and
jumping back and forth between the browser and Emacs to examine and edit
the code), then it's difficult to see how that can possibly be more
efficient than the mail-based, Emacs-based bug report system we have
today.

But seeing is believing, so proponents of new shinyness should
demonstrate the superior workflow.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Development suggestions from an ENSIME developer

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> and jumping back and forth between the browser and Emacs to examine
> and edit the code

And Emacs is special in this regard.  If what you're working on is
$(web-framework-of-the-day), it there is little advantage to getting a
bug report in your email client versus looking at it in a web browser.
If you want to test some breaking code, you have to cut and paste it
from where it is to where you want it to be and then test it.

In Emacs, if a user says "(this-does-not-work) doesn't work", since what
you're testing is what you're reading the bug report in, you can just
execute it and see that it doesn't work and then fix it.

In that sense, Emacs is a special snow flake.  The unfortunate effect of
this extreme ease (resulting from the high level of Emacs integration
with everything) is that there's more stuff for new developers to get
used to.

If only debbugs had a sensible web interface, too, then it would be less
daunting for new people, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Development suggestions from an ENSIME developer

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

On Fri, Jul 22, 2016 at 7:48 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> If only debbugs had a sensible web interface, too, then it would be less
> daunting for new people, I think.
>

​Bingo.  It doesn't really look like any effort was put into building a web
interface that would work for people who have used any other issue trackers
in the past.  It should at least have a google-like search field that lets
one quickly search for bugs based on subject line, bug id or the full text
of discussions, so one does not have to master any field-based searching
initially.

And maybe server request processing speed could be increased for queries
that return hundreds or a few thousand records.

Bob

[-- Attachment #2: Type: text/html, Size: 1496 bytes --]

Re: Development suggestions from an ENSIME developer

[Eli Zaretskii]

> From: Robert Weiner <rsw@gnu.org>
> Date: Fri, 22 Jul 2016 09:00:40 -0400
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> It should at least have a google-like search field that lets one
> quickly search for bugs based on subject line, bug id or the full text of discussions, so one does not have to
> master any field-based searching initially.

That it does have, look near the end of the page.

Re: Development suggestions from an ENSIME developer

[Stefan Monnier]

> 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

Re: Development suggestions from an ENSIME developer

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Fri, Jul 22, 2016 at 9:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > It should at least have a google-like search field that lets one
> > quickly search for bugs based on subject line, bug id or the full text
> of discussions, so one does not have to
> > master any field-based searching initially.
>
> That it does have, look near the end of the page.


​Good.  The results seem to come back reasonably quickly as well.​

​I would suggest the following for the web interface:
  - the full text search field ​be added to the home page and be near the
top so casual users find it right away and everyone can use it quickly with
navigating to a separate page
  - that the status/pending of the issue be displayed (right now only
severity is displayed)
  - that there be an easy way to navigate from a full text search result
connected to a specific bug
    to a place where a new comment can be added or a status can be changed
(with the appropriate authority)

Bob

[-- Attachment #2: Type: text/html, Size: 2000 bytes --]

Re: Development suggestions from an ENSIME developer

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: phillip.lord@russet.org.uk (Phillip Lord),  emacs-devel@gnu.org
> Date: Fri, 22 Jul 2016 09:35:41 -0400
> 
> 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

For me, most of the work is between 1 and 2.  The decision whether the
patch looks good is often times not an easy one, it requires reading
more code than is directly affected by the patch, consult the
documentation, sometimes reading past discussions and bug reports,
sometimes trying the patched version.  That's the most time-consuming
part of patch review, and it isn't going to go away, nor (it seems)
will it be helped by the proposed changes in any way.

> 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.

For me, the annoying part is not the failure to apply the patch.  It's
the last touches I need to apply to the patch to make it up to our
standards.  In many cases, I hesitate to ask the submitter to do that,
either because there were already several iterations of the comments
and reviews, and I don't want to drive them off, or because explaining
what should be changed and how will take more time and effort than
just doing it and telling the submitter "look what I did and try to
follow in the future".  I don't expect these aspects to be helped in
any way, by any system.

> 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.

These are non-issues for me.  They seldom happen, and when they do,
it's easy to handle them.

> - hopefully/ideally the tool could have already checked copyright.list
>   for you.

Is there any system that does?  I doubt that.

> - "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).

Does the above really make sense in a project where most patches get
reviewed by a single person?

> 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...

I envision more complaints from submitters about the complexity of the
process...

Re: Development suggestions from an ENSIME developer

[Ted Zlatanov]

On Fri, 22 Jul 2016 12:46:14 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> But seeing is believing, so proponents of new shinyness should
LI> demonstrate the superior workflow.  :-)

The thread "debbugs tracker builds character" is getting there. We need
Gitlab to be approved as a tool choice before the rest can happen.

Ted

Re: Development suggestions from an ENSIME developer

[Stefan Monnier]

> For me, most of the work is between 1 and 2.  The decision whether the
> patch looks good is often times not an easy one, it requires reading
> more code than is directly affected by the patch, consult the
> documentation, sometimes reading past discussions and bug reports,
> sometimes trying the patched version.  That's the most time-consuming
> part of patch review, and it isn't going to go away, nor (it seems)
> will it be helped by the proposed changes in any way.

It's no silver bullet, no.  But the question was not "will it do the
work for me" but just "is it going to be better or worse".
I think it's going to be marginally better.

E.g. for step "1b", you get to look at the patch in the format you
like rather than in the format the submitter chose.

> For me, the annoying part is not the failure to apply the patch.  It's
> the last touches I need to apply to the patch to make it up to our
> standards.  In many cases, I hesitate to ask the submitter to do that,
> either because there were already several iterations of the comments
> and reviews, and I don't want to drive them off, or because explaining
> what should be changed and how will take more time and effort than
> just doing it and telling the submitter "look what I did and try to
> follow in the future".  I don't expect these aspects to be helped in
> any way, by any system.

Indeed, it will probably be just about the same in this respect.

> These are non-issues for me.  They seldom happen, and when they do,
> it's easy to handle them.

Mostly agreed, except for "a diff w.r.t the previous version of that
same merge request": I haven't needed it often, but the few times I did,
I found it excruciating to extract that info from emails.

>> - hopefully/ideally the tool could have already checked copyright.list
>> for you.
> Is there any system that does?  I doubt that.

Out of the box of course not.
But if it's got enough hooks, we should be able to add it ourselves.

>> - "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).
> Does the above really make sense in a project where most patches get
> reviewed by a single person?

If we want to improve our commit-logs, I think we need to reduce the
number of people who have full commit rights.  So while we probably
wouldn't be able to make any use of "half-commit" rights right now, it
could be very useful at some later time.

>> 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...
> I envision more complaints from submitters about the complexity of the
> process...

A few old timers might be annoyed, but I'd expect most other submitters
would welcome the change.


        Stefan

Re: Development suggestions from an ENSIME developer

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:
>> And I can only give you anecdotal evidence that it will make things
>> better after adoption.
>
> 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.
>
> My problem is with having to learn a new system just because it's
> considered (or even is) "newer" or "more shiny" or presents a prettier
> graphics than the old one.  These alone are IMO not enough to justify
> the effort of learning yet another tool.

All this is true. But a lot of the costs are about discoverabillity,
learnability, and so forth. A "how many keys do I need to press" will
not cover this.


>> > Also, I think the solution should support text-mode browsers, such as
>> > Lynx or Emacs's eww on TTY frames.  IOW, anything that requires GUI
>> > and won't work otherwise is probably out of question to begin with.
>> > (This requirement is not for me personally.)
>> 
>> If that is a hard requirement, then I think we are not going to get much
>> further with a web 2.0 program. The best option is going to be somewhere
>> to host clones for developers, and then use debbugs.
>> 
>> But, it really is a hard requirement.
>
> I don't know if this is a hard requirement, it isn't mine.  I don't
> use Lynx.  I do use Emacs on a TTY, for remotely accessing other
> machines, and I do sometimes need to be able to fix bugs and commit
> changes from such a remote session.  So a solution that can be
> reasonably used from a TTY frame in Emacs or from a shell prompt will
> be welcome.
>
> Also, if a Web interface is really required for all the proposed
> alternatives, then it means I'll have to leave Emacs and fire up a Web
> browser, right?  Because EWW, as good as it is (and it is good), is
> still not up to that level, is it?


Yes, probably.

FWIW, in my use of github (which I realise is not an option here, not am
I advocating it), I use a combination of the web interface and Emacs. I
create PRs on the web, follow discussion in Gnus, and update, squash and
manipulate in Emacs. When recieving PRs I normally use the web to view
and do the merge.

Phil

Re: Development suggestions from an ENSIME developer

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> For me, most of the work is between 1 and 2.  The decision whether the
>> patch looks good is often times not an easy one, it requires reading
>> more code than is directly affected by the patch, consult the
>> documentation, sometimes reading past discussions and bug reports,
>> sometimes trying the patched version.  That's the most time-consuming
>> part of patch review, and it isn't going to go away, nor (it seems)
>> will it be helped by the proposed changes in any way.
>
> It's no silver bullet, no.  But the question was not "will it do the
> work for me" but just "is it going to be better or worse".
> I think it's going to be marginally better.


I think neither of your mentioned "not be completely happy, and ask for
changes". Being able to do line-by-line comments is a big help. Then the
PR'er fixes, squashes. No new patch is needed, just look at the updated
state of the world.

I found when fiddling with the undo system that sometimes I didn't
understand Stefan's comments, because I wasn't sure which bit of code he
was talking about (my comprehension I am sure, rather than his
explanation).



>>> - hopefully/ideally the tool could have already checked copyright.list
>>> for you.
>> Is there any system that does?  I doubt that.
>
> Out of the box of course not.
> But if it's got enough hooks, we should be able to add it ourselves.


Copyright.list, no, undoubtly not, but other systems do indeed do CLA
signatures and checking.


>>> - "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).
>> Does the above really make sense in a project where most patches get
>> reviewed by a single person?
>
> If we want to improve our commit-logs, I think we need to reduce the
> number of people who have full commit rights.  So while we probably
> wouldn't be able to make any use of "half-commit" rights right now, it
> could be very useful at some later time.

And, actually, removing full commit rights would probably *increase* the
number of commiters.

I'm still a little nervous when commit to head, because I worry about
screwing things up. Submitting a PR is much less of a nervous process. I
find this is true even for projects where I do have commit rights. Some
projects use PRs even for commiters, so everything goes through two
pairs of eyes.

Probably not going to be good for all of Emacs, but for some of it, it's
going to be good.


>>> 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...
>> I envision more complaints from submitters about the complexity of the
>> process...
>
> A few old timers might be annoyed, but I'd expect most other submitters
> would welcome the change.


Especially if people are familiar with it already.

Phil

Re: Development suggestions from an ENSIME developer

[Robert Cochran]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> I for one would welcome a code of conduct :) These things tend to send
> an explicit positive message, and there are virtually no downsides to
> having one.

I disagree.

When I think 'Code of Conduct', I inevitably think of the Social Justice
Warriors. I think very lowly of the SJWs, and I'm always set on edge, at
least a little, when I see that a project has adopted a CoC. That tends
to be an indicator that the SJWs have infected a project.

See http://esr.ibiblio.org/?p=6918 for a larger picture. Let me leave
you with this excerpt to set the stage (slightly adjusted to better fit
ASCII):

> Rosario tagged his Twitter report "Social Justice in action!" He knows
> who these people are: SJWs, "Social Justice Warriors". And, unless you
> have been living under a rock, so do you. These are the people – the
> political and doctrinal tendency, united if in no other way by an
> elaborate shared jargon and a seething hatred of djangoconcardiff’s
> "white straight male", who recently hounded Nobel laureate Tim Hunt out
> of his job with a /fraudulent/ accusation of sexist remarks.

I'd personally advocate for no code at all. "Be an adult, not an
asshole". Anyone that needs common decency rules spelled out for them
is probably not a good candidate for contributing, IMO.

If we must have a code, I'd pick something like the "Code of Merit"
(http://code-of-merit.org/), that makes it explicitly clear we are here
to write software, not to coddle people.

I know that I'm a relative newcomer to the Emacs lists, and that my
opinion isn't going to be as highly esteemed as some, but this issue is
important to me and I feel like I need to make my voice heard.

Thanks,
~Robert Cochran

Re: Development suggestions from an ENSIME developer

[Eli Zaretskii]

> From: Robert Cochran <robert-emacs@cochranmail.com>
> Date: Fri, 22 Jul 2016 15:48:49 -0700
> Cc: emacs-devel@gnu.org
> 
> I know that I'm a relative newcomer to the Emacs lists, and that my
> opinion isn't going to be as highly esteemed as some, but this issue is
> important to me and I feel like I need to make my voice heard.

It has been heard, thanks.

There was never any need to have a code of conduct on the Emacs lists,
and I don't see any need for that now.  Telling people to be nice is
not useful: it has effect only on those who already are.  Telling them
not to be assholes can in some quarters rightfully be interpreted as
an offense to their intelligence.  Etc. etc.  Frankly, having read the
proponents of such a code in the discussion that triggered this one, I
think at least some of them should look in the mirror before they
preach others.

The only conduct we don't tolerate here is extreme rudeness far beyond
any reasonably-civilized behavior.  And even that needs to be repeated
several times, before some kind of "police action" will be taken.
There were very few, maybe two or three, of such cases here.  In other
cases, people might be politely told to take some irrelevant
discussion elsewhere (and even that happens only if a small group is
interested in that topic).

And that's how it should be, IMO: we should not shut up discussions or
oust their originators just because we don't like the way they express
their opinions, or how they format their messages.  A movement that
aspires to bring more freedom cannot IMO manage its forums in any
other way.

Re: Development suggestions from an ENSIME developer

[Lars Ingebrigtsen]

Robert Cochran <robert-emacs@cochranmail.com> writes:

> When I think 'Code of Conduct', I inevitably think of the Social Justice
> Warriors. I think very lowly of the SJWs, and I'm always set on edge, at
> least a little, when I see that a project has adopted a CoC. That tends
> to be an indicator that the SJWs have infected a project.

If that's the logic, then I'm all for Emacs having a code of conduct
document.

If what you are saying is true, not having one sounds like it's a sign
that Male Rights Activists have taken over the project.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Development suggestions from an ENSIME developer

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1322 bytes --]

On 2016-07-22 18:48, Robert Cochran wrote:
>>> I for one would welcome a code of conduct :) These things tend to
>>> send an explicit positive message, and there are virtually no
>>> downsides to having one.
> 
> I disagree.
> 
> When I think 'Code of Conduct', I inevitably think of the Social
> Justice Warriors. I think very lowly of the SJWs

Thanks for sharing your opinion.  If this is the only downside, I still stand by "virtually no downsides".

We have two groups of people: one that feels unsafe in some online communities, and which we might make more comfortable by explicitly stating that contributors should behave nicely to each other (which, as has been pointed out, is not asking much: this mailing list is rather civil already).  Another one that feels upset about such a document, based on vaguely accusatory inferences about who might have suggested the introduction of said document — although it doesn't affect them personally in any way.

> and I'm always set on edge, at least a little, when I see that a
> project has adopted a CoC. That tends to be an indicator that the
> SJWs have infected a project.

Conversely, I'm set on the edge when I see someone refer to "Social Justice Warriors", especially in the context of adopting a Code of Conduct :)

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Development suggestions from an ENSIME developer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > least a little, when I see that a project has adopted a CoC. That tends
  > > to be an indicator that the SJWs have infected a project.

  > If what you are saying is true, not having one sounds like it's a sign
  > that Male Rights Activists have taken over the project.  

That way of thinking rejects, a priori, anything other than two
erroneous extremes.  We must reject both statements.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Development suggestions from an ENSIME developer

[Phillip Lord]

I wasn't going to comment on this point, but I felt that your email
merited a response.

Robert Cochran <robert-emacs@cochranmail.com> writes:

> Clément Pit--Claudel <clement.pit@gmail.com> writes:
>
>> I for one would welcome a code of conduct :) These things tend to send
>> an explicit positive message, and there are virtually no downsides to
>> having one.
>
> I disagree.

This is one point that we agree with; CoC always remind me of the "Great
Loyality Crusade". In the end, these things can become a purpose in
themselves, as opposed their original intention.

> That tends to be an indicator that the SJWs have infected a project.

"infection" is a verb that we apply to disease. Personally, I find it
lacking in respect and rather worrisome to apply this to people what
ever we think of them. I feel the same about the use of "cancer" or "the
enemy within". I would ask that you do not do this.

You are welcome to describe this as political correctness; you'd even be
using the term correctly, which is a rarity these days.


> See http://esr.ibiblio.org/?p=6918 for a larger picture. Let me leave
> you with this excerpt to set the stage (slightly adjusted to better fit
> ASCII):
>
>> Rosario tagged his Twitter report "Social Justice in action!" He knows
>> who these people are: SJWs, "Social Justice Warriors". And, unless you
>> have been living under a rock, so do you. These are the people – the
>> political and doctrinal tendency, united if in no other way by an
>> elaborate shared jargon and a seething hatred of djangoconcardiff’s
>> "white straight male", who recently hounded Nobel laureate Tim Hunt out
>> of his job with a /fraudulent/ accusation of sexist remarks.

While I am very respectful of Eric's many talents, in the case of Tim
Hunt he is entirely incorrect. I am a biologist as well as a software
developer, I'm familiar with Tim's work and, of course, a greatly admire
it.

When I heard his statements reported (and which he then justified on
national radio), I considered them to be silly, but then felt that,
hopefully, he would have learned his lesson, and then we should just
forgive and forget.

But, then I discussed the issue with many of my colleagues; turns out,
that they were less willing to forgive. Actually, many of there were
extremely angry. Like me, science is a part of their life, a vocation
not an occupation. But, they had just heard a senior scientist describe
them as not good enough, prone to tears when criticised, just because
they are women. I was wrong; it's not my place to forgive and forget,
it's theirs.

I think Tim wasn't hounded out of his job by "social justice warriors";
I think he left out of embarrassment when he realised how many of his
colleagues he had deeply offended.


> I know that I'm a relative newcomer to the Emacs lists, and that my
> opinion isn't going to be as highly esteemed as some, but this issue is
> important to me and I feel like I need to make my voice heard.

As another relative newcomer, welcome to the mailing list.

Phil

Re: Development suggestions from an ENSIME developer

[Robert Cochran]

phillip.lord@russet.org.uk (Phillip Lord) writes:

>> That tends to be an indicator that the SJWs have infected a project.
>
> "infection" is a verb that we apply to disease. Personally, I find it
> lacking in respect and rather worrisome to apply this to people what
> ever we think of them. I feel the same about the use of "cancer" or "the
> enemy within". I would ask that you do not do this.
>
> You are welcome to describe this as political correctness; you'd even be
> using the term correctly, which is a rarity these days.

No, you're right. I got a little *too* zealous in showing my
disapproval. I'll keep that in mind for future communications. Thank you
for pointing my failure out to me.

> While I am very respectful of Eric's many talents, in the case of Tim
> Hunt he is entirely incorrect. I am a biologist as well as a software
> developer, I'm familiar with Tim's work and, of course, a greatly admire
> it.
>
> When I heard his statements reported (and which he then justified on
> national radio), I considered them to be silly, but then felt that,
> hopefully, he would have learned his lesson, and then we should just
> forgive and forget.
>
> But, then I discussed the issue with many of my colleagues; turns out,
> that they were less willing to forgive. Actually, many of there were
> extremely angry. Like me, science is a part of their life, a vocation
> not an occupation. But, they had just heard a senior scientist describe
> them as not good enough, prone to tears when criticised, just because
> they are women. I was wrong; it's not my place to forgive and forget,
> it's theirs.
>
> I think Tim wasn't hounded out of his job by "social justice warriors";
> I think he left out of embarrassment when he realised how many of his
> colleagues he had deeply offended.

Well, now I have no idea which story is more accurate. I'll go ahead and
just drop that aspect in this and future discussions on the topic, then.
I'd prefer that than spreading any potential mis-information.

> As another relative newcomer, welcome to the mailing list.

Thank you.

~Robert Cochran

Re: Development suggestions from an ENSIME developer

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

>>>>> "CP" == Clément Pit--Claudel <clement.pit@gmail.com> writes:

CP> I for one would welcome a code of conduct :) These things tend to send an
PC> explicit positive message, and there are virtually no downsides to having
PC> one. LibrePlanet, Mailman, and GNU Health already seem to have one.

Hi Clément,

I appreciate the desire for a code of conduct, which is that we should all be
courteous and respectful of one another, united in our common effort to build
the future of Emacs.

If I thought having a code of conduct would make any difference, we would have
one. However, its mere existence does not stop anyone from saying whatever
they want; and its absence does not stop me from withdrawing their right to
post if I feel their contributions are inappropriate (and this list _is_
moderated, though no one has ever been filtered yet).

When people become abrasive or discouraging to others, I say something about
it. But even if a code of conduct existed, and said the same thing, I would
still need to repeat it here. The published document does not save me the
effort, since the problem exists _here_.

Some make the argument that publishing a code of conduct announces to others
what our standards are, and that we are accepting of all peoples, of all
persuasions. If we think this is what we've been missing to win new users,
that's certainly something to consider; but the fact is, everyone IS welcome,
abuse of any kind is NOT tolerated, and I think the people contributing here
already know that.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Development suggestions from an ENSIME developer

[Alex Dunn]

John Wiegley <jwiegley@gmail.com> writes:

> Some make the argument that publishing a code of conduct announces to others
> what our standards are, and that we are accepting of all peoples, of all
> persuasions.

It does this, and it’s good to have it formalized, but it’s also a very
useful way to signal that the community has chosen to adopt a certain
stance; namely one according to which social justice _is_ important.  If
this upsets people who sneer at “SJWs” and share ESR’s paranoid
fantasies about feminists trying to honeypot Linus, then so much the
better.  A community can’t be welcoming to everyone, when some groups
are openly antagonistic toward others.  A code of conduct helps clarify
which groups can expect to feel welcome in a community, and which aren’t
(e.g., those who compare CoCs to nuclear weapons:
https://github.com/fontforge/fontforge/issues/2765#issuecomment-237721149).