"If you're still seeing problems, please reopen." [Was: bug#25148:]

"If you're still seeing problems, please reopen." [Was: bug#25148:]

[Alan Mackenzie]

In article <mailman.1688.1573976224.13325.bug-gnu-emacs@gnu.org> you wrote:

[ .... ]

> If you're still seeing problems, please reopen.

Yes, but how?

The OP of a bug report is not going to be able to reopen it, since the
way to do this is so arcane and obscure.  You're not giving her a fair
chance!

If you're sincere about OPs reopening closed bugs, how about giving them
a recipe to do so, or at least a pointer to the doc which explains how
to?

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

>> If you're still seeing problems, please reopen.
>
> Yes, but how?

Just responding is enough, and then somebody who knows how will reopen.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>>> If you're still seeing problems, please reopen.
>>
>> Yes, but how?
>
> Just responding is enough, and then somebody who knows how will reopen.

IMO this is not satisfactory. The message says "do this", but there
is no clue about how to do "this".

Debbugs is the most user-hostile bug tracking system that I deal with.
In fact, I don't consider it a bug tracking system at all: it is a poor
mailing list with some attached hacks for associating tags to threads.

Please kill Debbugs.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> IMO this is not satisfactory. The message says "do this", but there
> is no clue about how to do "this".
>
> Debbugs is the most user-hostile bug tracking system that I deal with.

All the user has to do is hit the "reply" button in the mail reader
they're using.  How is that user-hostile?

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> IMO this is not satisfactory. The message says "do this", but there
>> is no clue about how to do "this".
>>
>> Debbugs is the most user-hostile bug tracking system that I deal with.
>
> All the user has to do is hit the "reply" button in the mail reader
> they're using.  How is that user-hostile?

The message says "reopen", not "reply".

And how is it acceptable to depend on the willingness and availability
of somebody else to effectively reopen the bug?

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

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

  > > All the user has to do is hit the "reply" button in the mail reader
  > > they're using.  How is that user-hostile?

  > The message says "reopen", not "reply".

That is a valid point -- but the fix to explain this should be simple.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 17 Nov 2019 18:49:10 +0100
> Cc: emacs-devel@gnu.org
> 
> > Debbugs is the most user-hostile bug tracking system that I deal with.
> 
> All the user has to do is hit the "reply" button in the mail reader
> they're using.  How is that user-hostile?

It's "the most user-hostile bug tracking system" in the same sense as
democracy is the worst form of government.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 17.11.2019 19:49, Lars Ingebrigtsen wrote:
> All the user has to do is hit the "reply" button in the mail reader
> they're using.  How is that user-hostile?

It's like an adventure computer game where you need to type what to do, 
what do say, etc. Heartwarming to someone who grew up in that era and, 
like, 30 years out of date.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 17.11.2019 19:49, Lars Ingebrigtsen wrote:
>> All the user has to do is hit the "reply" button in the mail reader
>> they're using.  How is that user-hostile?
>
> It's like an adventure computer game where you need to type what to
> do, what do say, etc. Heartwarming to someone who grew up in that era
> and, like, 30 years out of date.

Users don't need to do any of that -- they just send and email, and us
busy bee Emacs peeps issue the magical incantations.

It's a Mechanical Turk kind of bug tracker.  But it sure is user
friendly.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 17.11.2019 20:09, Lars Ingebrigtsen wrote:
> Users don't need to do any of that -- they just send and email

They don't know that. And a certain percentage *will* be too shy to do 
anything for fear of bothering anybody.

Some other percentage will spend 10 minutes googling "how to freaking 
close a Debbugs bug report", then do that, and then do that again 
several months later (if they don't open/close bugs here often). I 
am/was like that myself.

There's nothing friendly about that process, by modern standards.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Andreas Schwab]

On Nov 17 2019, Dmitry Gutov wrote:

> There's nothing friendly about that process, by modern standards.

It is user-friendly like Unix.  That's why it will still be around in 25
years.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 17.11.2019 20:09, Lars Ingebrigtsen wrote:
>> Users don't need to do any of that -- they just send and email
>
> They don't know that. And a certain percentage *will* be too shy to do
> anything for fear of bothering anybody.

OK, I'll start saying "send a mail to reopen" or something.

> Some other percentage will spend 10 minutes googling "how to freaking
> close a Debbugs bug report", then do that, and then do that again 
> several months later (if they don't open/close bugs here often). I
> am/was like that myself.
>
> There's nothing friendly about that process, by modern standards.

That's developer unfriendliness, not user unfriendliness, in my opinion.
And I don't remember those details at all -- that's why we have
debbugs-gnu, which is a lot friendlier (to me) than any web-based bug
tracker.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 17.11.2019 20:36, Lars Ingebrigtsen wrote:
> That's developer unfriendliness, not user unfriendliness, in my opinion.

No, we expect end users to file reports through Debbugs. And then, 
apparently, be able to close them.

> And I don't remember those details at all -- that's why we have
> debbugs-gnu, which is a lot friendlier (to me) than any web-based bug
> tracker.

That's for us, not them.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 17.11.2019 20:36, Lars Ingebrigtsen wrote:
>> That's developer unfriendliness, not user unfriendliness, in my opinion.
>
> No, we expect end users to file reports through Debbugs. And then,
> apparently, be able to close them.

I've never expected a user to be able to close a bug.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 17 Nov 2019 20:37:26 +0200
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> On 17.11.2019 20:36, Lars Ingebrigtsen wrote:
> > That's developer unfriendliness, not user unfriendliness, in my opinion.
> 
> No, we expect end users to file reports through Debbugs. And then, 
> apparently, be able to close them.

No, we don't expect them to close bugs, not normally.  Just to file
them, which boils down to sending an email to a certain address.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > They don't know that. And a certain percentage *will* be too shy to do
> > anything for fear of bothering anybody.
>
> OK, I'll start saying "send a mail to reopen" or something.

I'll update my yasnippets do the same.

I think saying "please reply to this email with your observations"
should be sufficient, rather than adding the full instructions for how
to reopen the bug.  If the user clicks "reply", it will reach me and I
can forward it to the bug tracker and reopen the bug.

Best regards,
Stefan Kangas

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I think saying "please reply to this email with your observations"
> should be sufficient, rather than adding the full instructions for how
> to reopen the bug.  If the user clicks "reply", it will reach me and I
> can forward it to the bug tracker and reopen the bug.

Yup.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Robert Pluim]

>>>>> On Tue, 19 Nov 2019 09:27:40 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Stefan Kangas <stefan@marxist.se> writes:
    >> I think saying "please reply to this email with your observations"
    >> should be sufficient, rather than adding the full instructions for how
    >> to reopen the bug.  If the user clicks "reply", it will reach me and I
    >> can forward it to the bug tracker and reopen the bug.

"Please reply-all to this email with your observations within 28
days", [1] since there might be other people on the CC, and after 28
days the bug is archived and canʼt be changed without unarchiving first.

Robert

Footnotes:
[1]  Why does debbugs not just let you send mail to closed bugs forever?

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Albinus]

Robert Pluim <rpluim@gmail.com> writes:


> [1]  Why does debbugs not just let you send mail to closed bugs forever?

That's the difference between "closed" and "archived". Debbugs let you
send messages "forever", but it tells you that your message is not
appended to the bug log when archived.

Technically, there are different databases were the archived and
non-archived bugs are stored. And for several operations, like
retrieving bugs according to filter criteria, you can specify, whether
archived bugs shall be retrieved as well. Usually, you don't want.

> Robert

Best regards, Michael.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> "Please reply-all to this email with your observations within 28
> days", [1] since there might be other people on the CC, and after 28
> days the bug is archived and canʼt be changed without unarchiving first.

I don't think any users has to know anything about the minutiae of
Debbugs -- that's for Emacs bug responders to fiddle with.  (I.e.,
unarchiving/reopening/etc.)

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Zach Pearson]

Hi all,

Supposing one wanted to assist in adding the requisite features to
GitLab, where would one go to do so? 

Is this issue https://gitlab.com/gitlab-org/gitlab/issues/28152 the
right location, or is the conversation about setting up a custom
instance on a maintainer-operated server?

Thanks, 

Zach 

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

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

  > > Users don't need to do any of that -- they just send and email

  > They don't know that.

What exactly would it be good for users to know?
When and how can we tell them?

  > Some other percentage will spend 10 minutes googling "how to freaking 
  > close a Debbugs bug report",

Who are the people that ought to close bug reports
and wouldn't know how?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 19.11.2019 8:09, Richard Stallman wrote:
> [[[ 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. ]]]
> 
>    > > Users don't need to do any of that -- they just send and email
> 
>    > They don't know that.
> 
> What exactly would it be good for users to know?

How to do simple things with the bug tracker, like closing the bug 
(there are more actions one is normally accustomed to being able to do, 
though).

> When and how can we tell them?

A decent Web UI could do that. But since Debbugs does not have it, we 
could write the instructions "how to do that over email" somewhere in 
the bug report page, among all the other text most users just skip over.

>    > Some other percentage will spend 10 minutes googling "how to freaking
>    > close a Debbugs bug report",
> 
> Who are the people that ought to close bug reports
> and wouldn't know how?

Regular users who filed said reports in the first place.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 19 Nov 2019 13:14:18 +0200
> Cc: ofv@wanadoo.es, larsi@gnus.org, emacs-devel@gnu.org
> 
> A decent Web UI could do that. But since Debbugs does not have it

Debbugs does have a Web UI, it just doesn't allow changing the
database through that UI.  You can only read the bugs and search the
database.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Heerdegen]

Richard Stallman <rms@gnu.org> writes:

> What exactly would it be good for users to know?
> When and how can we tell them?

There is another, related problem (it was already posted to this group
but got no answers):

M-x report-emacs-bug is not even always a good way to file Emacs bug
reports.  For example, the org developers wish that org related bug
reports appear in their own list - org-mode bugs reported to
gnu.emacs.bug get no attention for years.

This works automatically when you use M-x org-submit-bug-report - but I
didn't find that command, even though I searched for it, because the
name doesn't fit the naming scheme report-.*-bug.  Other users will not
even know that some packages may have special commands for bug reporting.

And other Emacs packages use even different naming schemes:

calc-report-bug
reftex-report-bug
eshell-report-bug
gnuplot-bug-report
c-submit-bug-report

Though several modes are also using the naming similar to
org-submit-bug-report:

c-submit-bug-report
diredp-send-bug-report
org-edna-submit-bug-report

Citing more text from Ihor's original message:

| I am thinking if it would make sense to develop more standardised
| command name conventions for bug reporting and add them to
| (elisp)Emacs Lisp:Preparing Lisp code for distribution
|
| Then, the built-in emacs packages might be changed to follow those
| conventions and improve discoverability of bug reporting capabilities.
|
| Also, an information that different major modes may have they own bug
| reporting tools might be mentioned in the default template shown in
| report-emacs-bug.
|
| What do you think?

I think this is a problem that also confuses and discourages users to
make bug reports, so - any opinions?

Oh, and a happy New Year to all of you!

Michael.

RE: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Drew Adams]

> > What exactly would it be good for users to know?
> > When and how can we tell them?
> 
> There is another, related problem (it was already posted to this group
> but got no answers):
> 
> M-x report-emacs-bug is not even always a good way to file Emacs bug
> reports.  For example, the org developers wish that org related bug
> reports appear in their own list - org-mode bugs reported to
> gnu.emacs.bug get no attention for years.
> 
> This works automatically when you use M-x org-submit-bug-report - but I
> didn't find that command, even though I searched for it, because the
> name doesn't fit the naming scheme report-.*-bug.  Other users will not
> even know that some packages may have special commands for bug
> reporting.
> 
> And other Emacs packages use even different naming schemes:
> 
> calc-report-bug
> reftex-report-bug
> eshell-report-bug
> gnuplot-bug-report
> c-submit-bug-report
> 
> Though several modes are also using the naming similar to
> org-submit-bug-report:
> 
> c-submit-bug-report
> diredp-send-bug-report
> org-edna-submit-bug-report
> 
> Oh, and a happy New Year to all of you!


Ditto - Happy new year, to all.

---

You ask how a user can find out how to submit
a bug report for a given library/package.

Good question.  It's not so easy - there are
several places a user might look for such info.
To be helpful, you have to cover a few of them.

---

Here's what I do, FWIW:

1. `C-h m' gives the mode doc (many libraries
have one or more main modes, major or minor).

That help prominently tells you how to submit
a bug report.  E.g.:

  Send a Dired+ bug report:
  'M-x diredp-send-bug-report'

(For my libraries I use "send" as the verb,
not "submit" or "report", because you send me
an email to report the bug.)

2. For a customize group (many libraries have
one), `M-x customize-group' shows a Customize
buffer for the group.  A title/description of
the group is just above the `State' button.
Just under the `State' button are some links,
one of which is, for my libraries, `Send Bug
Report'.

That's provided by :link with a `url-link' of
"mailto:" with template text that fills out
email address, library name, and instructions.

3. Similarly, each global `define-minor-mode'
I define has a bug-report email :link.  (Not
that many people will actually use Customize
for the mode, but why not?)

4. I mention the command to send a bug report
in the library doc.

If I had to guess, I'd guess that users come
across the info most often in the doc (which
is also on the web) or from `C-h m'.

---

It's also possible to add a menu item to the
`Help' menu for help on the major mode of a
buffer, i.e., for `C-h m'.  It might even be
good for Emacs to do that systematically.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[VanL]

>> > What exactly would it be good for users to know?
>> > When and how can we tell them?
>> 
>> There is another, related problem (it was already posted to this group
>> but got no answers):
>> 
>> M-x report-emacs-bug is not even always a good way to file Emacs bug
>> reports.  For example, the org developers wish that org related bug
>> reports appear in their own list - org-mode bugs reported to
>> gnu.emacs.bug get no attention for years.
>> 
>> This works automatically when you use M-x org-submit-bug-report - but I
>> didn't find that command, even though I searched for it, because the
>> name doesn't fit the naming scheme report-.*-bug.  Other users will not
>> even know that some packages may have special commands for bug
>> reporting.
>> 
>> And other Emacs packages use even different naming schemes:
>> 
>> calc-report-bug
>> reftex-report-bug
>> eshell-report-bug
>> gnuplot-bug-report
>> c-submit-bug-report
>> 
>> Though several modes are also using the naming similar to
>> org-submit-bug-report:
>> 
>> c-submit-bug-report
>> diredp-send-bug-report
>> org-edna-submit-bug-report

Like how M-x icomplete-mode works, what if the Emacs user does the
following to find the right channel for reporting a bug to?

1. <S-return>
   Summons the neural inference engine's interactive prompt.
   Gotcha, org-mode uses <S-return> for something else.

2. type: bug
   All the possible channels are displayed for reporting a bug to.
   For example, like how M-x occur shows a listing to pick from.

HNY.

ps. I wasn't able to reply to EB's off-list email, the data session is
    rejected.  I don't know why.  Maybe operators are on holidays.

-- 
 əə0@ 7 6 4 5 bit byte word 6 5 0 2 memory map dma intelligence io 🐞
 一 二 三 言 語 𝔖 元 示 証 明 海 自 己 漢 本 人 Gnus/Emacs (berkeley-unix)

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Wed, 01 Jan 2020 02:19:42 +0100
> Cc: ofv@wanadoo.es, larsi@gnus.org, emacs-devel@gnu.org,
>  Ihor Radchenko <yantar92@gmail.com>, Dmitry Gutov <dgutov@yandex.ru>
> 
> | I am thinking if it would make sense to develop more standardised
> | command name conventions for bug reporting and add them to
> | (elisp)Emacs Lisp:Preparing Lisp code for distribution
> |
> | Then, the built-in emacs packages might be changed to follow those
> | conventions and improve discoverability of bug reporting capabilities.
> |
> | Also, an information that different major modes may have they own bug
> | reporting tools might be mentioned in the default template shown in
> | report-emacs-bug.
> |
> | What do you think?
> 
> I think this is a problem that also confuses and discourages users to
> make bug reports, so - any opinions?

I don't really believe on relying on discoverability in this case.
Even if users will discover the various commands, they might not know
which one to invoke.

How about if we add a bug-reporting-function, to be set by any mode
that wants to override the default one (which sends email to debbugs)?
Then report-emacs-bug could be modified to detect the modes active in
the buffer, and suggest the possible alternatives to the user.  I
think adding to our coding conventions a single variable that in most
cases doesn't even have to be set will be easier to propagate to the
few modes which want their own bug-tracking.  And users will benefit
from not having to search high and low for the relevant command.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Ihor Radchenko]

> How about if we add a bug-reporting-function, to be set by any mode
> that wants to override the default one (which sends email to debbugs)?
> Then report-emacs-bug could be modified to detect the modes active in
> the buffer, and suggest the possible alternatives to the user.  I
> think adding to our coding conventions a single variable that in most
> cases doesn't even have to be set will be easier to propagate to the
> few modes which want their own bug-tracking.  And users will benefit
> from not having to search high and low for the relevant command.

This sounds reasonable. 

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Heerdegen <michael_heerdegen@web.de>
>> Date: Wed, 01 Jan 2020 02:19:42 +0100
>> Cc: ofv@wanadoo.es, larsi@gnus.org, emacs-devel@gnu.org,
>>  Ihor Radchenko <yantar92@gmail.com>, Dmitry Gutov <dgutov@yandex.ru>
>> 
>> | I am thinking if it would make sense to develop more standardised
>> | command name conventions for bug reporting and add them to
>> | (elisp)Emacs Lisp:Preparing Lisp code for distribution
>> |
>> | Then, the built-in emacs packages might be changed to follow those
>> | conventions and improve discoverability of bug reporting capabilities.
>> |
>> | Also, an information that different major modes may have they own bug
>> | reporting tools might be mentioned in the default template shown in
>> | report-emacs-bug.
>> |
>> | What do you think?
>> 
>> I think this is a problem that also confuses and discourages users to
>> make bug reports, so - any opinions?
>
> I don't really believe on relying on discoverability in this case.
> Even if users will discover the various commands, they might not know
> which one to invoke.
>
> How about if we add a bug-reporting-function, to be set by any mode
> that wants to override the default one (which sends email to debbugs)?
> Then report-emacs-bug could be modified to detect the modes active in
> the buffer, and suggest the possible alternatives to the user.  I
> think adding to our coding conventions a single variable that in most
> cases doesn't even have to be set will be easier to propagate to the
> few modes which want their own bug-tracking.  And users will benefit
> from not having to search high and low for the relevant command.

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> How about if we add a bug-reporting-function, to be set by any mode
> that wants to override the default one (which sends email to debbugs)?
> Then report-emacs-bug could be modified to detect the modes active in
> the buffer, and suggest the possible alternatives to the user.  I
> think adding to our coding conventions a single variable that in most
> cases doesn't even have to be set will be easier to propagate to the
> few modes which want their own bug-tracking.  And users will benefit
> from not having to search high and low for the relevant command.

Sounds good, yes.  But as you describe it, it doesn't cover those cases
where people invoke the command from an unrelated buffer (*scratch* or
so), e.g. because they needed to restart Emacs.  Adding some
explanations to the initial text in the bug report buffer of the default
reporting command would thus be good I think.

Michael.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Welsh Duggan]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> How about if we add a bug-reporting-function, to be set by any mode
>> that wants to override the default one (which sends email to debbugs)?
>> Then report-emacs-bug could be modified to detect the modes active in
>> the buffer, and suggest the possible alternatives to the user.  I
>> think adding to our coding conventions a single variable that in most
>> cases doesn't even have to be set will be easier to propagate to the
>> few modes which want their own bug-tracking.  And users will benefit
>> from not having to search high and low for the relevant command.
>
> Sounds good, yes.  But as you describe it, it doesn't cover those cases
> where people invoke the command from an unrelated buffer (*scratch* or
> so), e.g. because they needed to restart Emacs.  Adding some
> explanations to the initial text in the bug report buffer of the default
> reporting command would thus be good I think.

Another possibility is that at some point in the bug reporting process
Emacs could query as to which mode is having problems.  This could
default to the current major mode (if there is a bug reporting function
specific to that mode) and could contain generic categories such as
"emacs" or "other".  If the selected mode has a specific bug-reporting
function associated with it, that bug-reporting function could be called
instead of the generic function.  As a bonus, even with a generic
bug report, we might get a possibly useful user-selected mode field.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> How about if we add a bug-reporting-function, to be set by any mode
>> that wants to override the default one (which sends email to debbugs)?
>> Then report-emacs-bug could be modified to detect the modes active in
>> the buffer, and suggest the possible alternatives to the user.  I
>> think adding to our coding conventions a single variable that in most
>> cases doesn't even have to be set will be easier to propagate to the
>> few modes which want their own bug-tracking.  And users will benefit
>> from not having to search high and low for the relevant command.
>
> Sounds good, yes.  But as you describe it, it doesn't cover those cases
> where people invoke the command from an unrelated buffer (*scratch* or
> so), e.g. because they needed to restart Emacs.  Adding some
> explanations to the initial text in the bug report buffer of the default
> reporting command would thus be good I think.

Yeah, people aren't necessarily in a relevant buffer when doing bug
reporting for a particular mode.  But I guess it wouldn't hurt allowing
modes to set the bugs package name automatically.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Juanma Barranquero]

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

On Sun, Nov 17, 2019 at 7:10 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> It's a Mechanical Turk kind of bug tracker.  But it sure is user
> friendly.

In this time and day, "user friendly" would be to have a clean, modern web
interface for the user to report new issues, follow them, etc.

What we have can be totally driven by e-mail (that was an absolute
prerequisite, IIRC) and it's relatively flexible. But user-friendly, if
you're not an old hand or a power user, it's not IMHO.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

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

On Sun, Nov 17, 2019, 18:10 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > On 17.11.2019 19:49, Lars Ingebrigtsen wrote:
> >> All the user has to do is hit the "reply" button in the mail reader
> >> they're using.  How is that user-hostile?
> >
> > It's like an adventure computer game where you need to type what to
> > do, what do say, etc. Heartwarming to someone who grew up in that era
> > and, like, 30 years out of date.
>
> Users don't need to do any of that -- they just send and email, and us
> busy bee Emacs peeps issue the magical incantations.
>
> It's a Mechanical Turk kind of bug tracker.  But it sure is user
> friendly.
>

FWIW I agree. A bug tracker based on email only is a fine thing.

Now I just wish Gnus was much much faster with Gmail. That's what really
complicates things for me. Maybe I'm doing something wrong. Probably I
haven't studied Gnus enough.

João

>

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[dick.r.chiang]

JT> Now I just wish Gnus was much much faster with Gmail. That's what really
JT> complicates things for me.  Maybe I'm doing something wrong. Probably I
JT> haven't studied Gnus enough.

May I recommend https://github.com/dickmao/gnus-imap-walkthrough as a starting point
for your studies.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Amin Bandali]

dick.r.chiang@gmail.com writes:

> JT> Now I just wish Gnus was much much faster with Gmail. That's what really
> JT> complicates things for me.  Maybe I'm doing something wrong. Probably I
> JT> haven't studied Gnus enough.
>
> May I recommend https://github.com/dickmao/gnus-imap-walkthrough as a starting point
> for your studies.

If I may suggest, another great setup, which I’ve modelled my own after,
is: https://ericabrahamsen.net/tech/2014/oct/gnus-dovecot-lucene.html

Basically, fetch/synchronize mail to your local machine in Maildir
format using something like getmail or isync (mbsync is the command),
put a local imap server (e.g. dovecot) in front of it, and point Gnus’s
nnimap to it.  Advantages of this setup include offline access to the
emails, and blazing fast access/browsing, and flexible search setups.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

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

Thanks Amin and Dick for the tips. Last time I tried the offline method it
was 2011 and I gave up because I use Linux and OSX machines, and it's even
harder on Windows. The latter should cease to be a problem soon and I will
try these setups asap.

In your experience, how does this system sync with occasional usage from
Gmail's web interface? Also, does this mean debbugs-gnu will also work
offline?

João

On Sun, Nov 17, 2019, 22:19 Amin Bandali <bandali@gnu.org> wrote:

> dick.r.chiang@gmail.com writes:
>
> > JT> Now I just wish Gnus was much much faster with Gmail. That's what
> really
> > JT> complicates things for me.  Maybe I'm doing something wrong.
> Probably I
> > JT> haven't studied Gnus enough.
> >
> > May I recommend https://github.com/dickmao/gnus-imap-walkthrough as a
> starting point
> > for your studies.
>
> If I may suggest, another great setup, which I’ve modelled my own after,
> is: https://ericabrahamsen.net/tech/2014/oct/gnus-dovecot-lucene.html
>
> Basically, fetch/synchronize mail to your local machine in Maildir
> format using something like getmail or isync (mbsync is the command),
> put a local imap server (e.g. dovecot) in front of it, and point Gnus’s
> nnimap to it.  Advantages of this setup include offline access to the
> emails, and blazing fast access/browsing, and flexible search setups.
>

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Albinus]

João Távora <joaotavora@gmail.com> writes:

> Also, does this mean debbugs-gnu will also work offline?

It is not prepared for this.

> João

Best regards, Michael.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> Also, does this mean debbugs-gnu will also work offline?
>
> It is not prepared for this.

Actually...  :-)  It does support saving the list of bug statuses to a
file and just use that when opening the *Emacs Bugs* buffer.  But of
course, to read the bugs themselves, you have to have them on disk.  But
if you do (and I do), you can use debbugs-gnu offline.  Responding to
bugs and altering their statuses is also supported (through Gnus'
offline mode), and you can send off the status changes/responses when
you get online.

(The downloading bits aren't included in the debbugs code, but I can
push that if there's interest.)

I did some bug triage on the plane back from Australia a few years
back, but then I got served too much booze and decided to stop.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>>> Also, does this mean debbugs-gnu will also work offline?
>>
>> It is not prepared for this.
>
> Actually...  :-)  It does support saving the list of bug statuses to a
> file and just use that when opening the *Emacs Bugs* buffer.  But of
> course, to read the bugs themselves, you have to have them on disk.  But
> if you do (and I do), you can use debbugs-gnu offline.  Responding to
> bugs and altering their statuses is also supported (through Gnus'
> offline mode), and you can send off the status changes/responses when
> you get online.

> (The downloading bits aren't included in the debbugs code, but I can
> push that if there's interest.)

I have no idea how this worked for you, but I'm not against to improve
debbugs-gnu this way.

Best regards, Michael.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> I have no idea how this worked for you, but I'm not against to improve
> debbugs-gnu this way.

Let's see...  it must be this code that I found in my ~/.emacs now
combined with debbugs-gnu-save-cache.

But I don't know whether we want to encourage people to download all the
bug reports...

The main problem with this all is that it doesn't update the statuses of
anything -- there needs to be a "fetch new bug statuses and update"
command.  Hm.  Or did debbugs get one of those?  I vaguely feel that
I've asked that before.

(defun lars-offline-debbugs ()
  (interactive)
  (require 'debbugs-gnu)
  (setq debbugs-cache-data
	(with-temp-buffer
	  (insert-file "~/.emacs.d/debbugs-cache/list")
	  (read (current-buffer))))
  (setq debbugs-cache-expiry nil)
  (debbugs-gnu-show-reports t))

(defun lars-download-bugs ()
  (maphash (lambda (key val)
	     (when (and (equal (cadr (assoc 'package val)) "emacs")
			(not (cdr (assoc 'done val))))
	       (let ((file (format "~/.emacs.d/debbugs-cache/%s" key)))
		 (unless (file-exists-p file)
		   (ignore-errors
		     (with-current-buffer (url-retrieve-synchronously
					   (format "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=%s;mboxmaint=yes;mboxstat=yes" key))
		       (write-region (point-min) (point-max) file)))
		   (sleep-for 5)))))
	   debbugs-cache-data))



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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But I don't know whether we want to encourage people to download all the
> bug reports...

Likely not. Maybe only for the bugs tagged locally.

> The main problem with this all is that it doesn't update the statuses of
> anything -- there needs to be a "fetch new bug statuses and update"
> command.

This wouldn't be offline anymore.

Best regards, Michael.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

>> The main problem with this all is that it doesn't update the statuses of
>> anything -- there needs to be a "fetch new bug statuses and update"
>> command.
>
> This wouldn't be offline anymore.

No, you'd update when you go online, and then you could go offline
again.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>>> The main problem with this all is that it doesn't update the statuses of
>>> anything -- there needs to be a "fetch new bug statuses and update"
>>> command.
>>
>> This wouldn't be offline anymore.
>
> No, you'd update when you go online, and then you could go offline
> again.

'C-u g' is supposed to refresh the bugs status in a debbugs-gnu list.

Best regards, Michael.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> 'C-u g' is supposed to refresh the bugs status in a debbugs-gnu list.

Hm...  This command?

(defun debbugs-gnu-rescan ()
  "Rescan the current set of bug reports."
  (interactive)
  (let ((id (debbugs-gnu-current-id))
	(debbugs-gnu-current-query debbugs-gnu-local-query)
	(debbugs-gnu-current-filter debbugs-gnu-local-filter)
	(debbugs-gnu-current-suppress debbugs-gnu-local-suppress)
	(debbugs-cache-expiry (if current-prefix-arg t debbugs-cache-expiry)))

Oh!  That's an odd way to do a prefix.  :-)

Following the logic, this all just results in a

(soap-invoke debbugs-wsdl debbugs-port "newest_bugs" amount)

call, which gives us...  the AMOUNT latest-changed bugs?  

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Andreas Schwab]

On Nov 18 2019, Lars Ingebrigtsen wrote:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> 'C-u g' is supposed to refresh the bugs status in a debbugs-gnu list.
>
> Hm...  This command?
>
> (defun debbugs-gnu-rescan ()
>   "Rescan the current set of bug reports."
>   (interactive)
>   (let ((id (debbugs-gnu-current-id))
> 	(debbugs-gnu-current-query debbugs-gnu-local-query)
> 	(debbugs-gnu-current-filter debbugs-gnu-local-filter)
> 	(debbugs-gnu-current-suppress debbugs-gnu-local-suppress)
> 	(debbugs-cache-expiry (if current-prefix-arg t debbugs-cache-expiry)))
>
> Oh!  That's an odd way to do a prefix.  :-)

I think any use of current-prefix-arg outside of an interactive spec is
a bug.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Albinus]

Andreas Schwab <schwab@suse.de> writes:

>> (defun debbugs-gnu-rescan ()
>>   "Rescan the current set of bug reports."
>>   (interactive)
>>   (let ((id (debbugs-gnu-current-id))
>> 	(debbugs-gnu-current-query debbugs-gnu-local-query)
>> 	(debbugs-gnu-current-filter debbugs-gnu-local-filter)
>> 	(debbugs-gnu-current-suppress debbugs-gnu-local-suppress)
>> 	(debbugs-cache-expiry (if current-prefix-arg t debbugs-cache-expiry)))
>>
>> Oh!  That's an odd way to do a prefix.  :-)
>
> I think any use of current-prefix-arg outside of an interactive spec is
> a bug.

I've fixed this.

> Andreas.

Best regards, Michael.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> 'C-u g' is supposed to refresh the bugs status in a debbugs-gnu list.
>
> Hm...  This command?
>
> (defun debbugs-gnu-rescan ()
>   "Rescan the current set of bug reports."
>   (interactive)
>   (let ((id (debbugs-gnu-current-id))
> 	(debbugs-gnu-current-query debbugs-gnu-local-query)
> 	(debbugs-gnu-current-filter debbugs-gnu-local-filter)
> 	(debbugs-gnu-current-suppress debbugs-gnu-local-suppress)
> 	(debbugs-cache-expiry (if current-prefix-arg t debbugs-cache-expiry)))
>
> Oh!  That's an odd way to do a prefix.  :-)
>
> Following the logic, this all just results in a
>
> (soap-invoke debbugs-wsdl debbugs-port "newest_bugs" amount)
>
> call, which gives us...  the AMOUNT latest-changed bugs?

No, in my case it is (according to *trace-output*)

| | | 4 -> (debbugs-soap-invoke-async "get_status" [38025 37954 37854 37557 37299 37168 36748 35769 35639 35473 35227 35129 34834 34322 34027 33146 33135 32941 32677 32645 32591 32544 32487 32426 30650 30463 30389 29735 28392 28320 27612 27397 26911 26387 26380 25214 25197 24472 23624 22466 20737 20246 20193 20016 18883 17361 16113 15687 14030 10160 9617 6850 4841 350])

Best regards, Michael.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[dick.r.chiang]

> In your experience, how does this system sync with occasional usage from
> Gmail's web interface?

If an incoming gmail triggers notification on my phone and Gnus, reading it on
one dismisses the notification on the other.  In other words, dovecot-mbsync
just works.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Amin Bandali]

João Távora <joaotavora@gmail.com> writes:

> Thanks Amin and Dick for the tips.

Cheers, João.

[...]
>
> In your experience, how does this system sync
> with occasional usage from Gmail's web
> interface? 

I don’t use Gmail but rather my own self-hosted
mail server, including a web interface.  FWIW,
my experience with using isync/mbsync for
synchronizing my mail and its state between the
dovecot on my laptop and the one running on my
mail server has been very smooth so far.  I’d
imagine Gmail to be somewhat similar.

> Also, does this mean debbugs-gnu will also
> work offline?
>
> João
>

Probably not, but I’m not sure.  I think Lars
and others more knowledgeable about the Debbugs
package have already replied and started
discussing about that, though. :)

Best,
amin

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 17 Nov 2019 20:06:32 +0200
> Cc: emacs-devel@gnu.org
> 
> On 17.11.2019 19:49, Lars Ingebrigtsen wrote:
> > All the user has to do is hit the "reply" button in the mail reader
> > they're using.  How is that user-hostile?
> 
> It's like an adventure computer game where you need to type what to do, 
> what do say, etc. Heartwarming to someone who grew up in that era and, 
> like, 30 years out of date.

The Adventure game was written around 1975, so it's more like 45
years.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

>> From: Dmitry Gutov <dgutov@yandex.ru>

>> On 17.11.2019 19:49, Lars Ingebrigtsen wrote:
>> > All the user has to do is hit the "reply" button in the mail reader
>> > they're using.  How is that user-hostile?

>> It's like an adventure computer game where you need to type what to
>> do, what do say, etc. Heartwarming to someone who grew up in that era
>> and, like, 30 years out of date.

> The Adventure game was written around 1975, so it's more like 45
> years.

I first encountered Adventure in 1982. It was 7 years old by then, but
still fun.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 17 Nov 2019 18:42:03 +0100
> 
> > Just responding is enough, and then somebody who knows how will reopen.
> 
> IMO this is not satisfactory. The message says "do this", but there
> is no clue about how to do "this".

Maybe we should mention admin/notes/bugtracker (which does describe
this) in CONTRIBUTE.

> Please kill Debbugs.

Please be serious.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 17.11.2019 19:59, Eli Zaretskii wrote:
> Maybe we should mention admin/notes/bugtracker (which does describe
> this) in CONTRIBUTE

Err, only a minority of people who have to use Debbugs will ever read 
CONTRIBUTE. (I hope.)

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 17 Nov 2019 20:11:57 +0200
> 
> On 17.11.2019 19:59, Eli Zaretskii wrote:
> > Maybe we should mention admin/notes/bugtracker (which does describe
> > this) in CONTRIBUTE
> 
> Err, only a minority of people who have to use Debbugs will ever read 
> CONTRIBUTE. (I hope.)

But even less people will read admin/notes/bugtracker.  So we might
gain some discoverability.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> IMO this is not satisfactory. The message says "do this", but there
>> is no clue about how to do "this".
>
> Maybe we should mention admin/notes/bugtracker (which does describe
> this) in CONTRIBUTE.
>
>> Please kill Debbugs.
>
> Please be serious.

I'm being absolutely serious. You are proposing to put a reference to a
650 line text file on a 400 line text file for solving something that is
self-evident on every other bug tracker.

Debbugs is the only user-facing bug tracker I know that requires
studying its magic incantations to complete tasks which are trivial on
any other system. Not to mention that, after all that studying, it still
won't provide basic features which exist and are trivial to use
elsewhere.

Debbugs is a non-starter for any project that expects interaction with
its user base.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 17 Nov 2019 19:25:38 +0100
> 
> > Please be serious.
> 
> I'm being absolutely serious.

Then you are simply wrong.

> Debbugs is a non-starter for any project that expects interaction with
> its user base.

A bug tracker should first and foremost help those who work on
triaging and fixing bugs.  I have experience with 3 other issue
tracking systems, and none of them is significantly better in this
aspect; some are worse.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Debbugs is a non-starter for any project that expects interaction with
>> its user base.
>
> A bug tracker should first and foremost help those who work on
> triaging and fixing bugs.

I disagree with you on this. A user-facing bug tracker must be welcoming
to users, otherwise you will miss many of those bugs.

> I have experience with 3 other issue
> tracking systems, and none of them is significantly better in this
> aspect; some are worse.

Maybe we should consider some of those which are not "significantly
better" at triaging and fixing bugs but are much better at interfacing
with end users and occasional contributors?

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Alan Mackenzie]

Hello, Óscar.

On Sun, Nov 17, 2019 at 20:07:12 +0100, Óscar Fuentes wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> Debbugs is a non-starter for any project that expects interaction with
> >> its user base.

> > A bug tracker should first and foremost help those who work on
> > triaging and fixing bugs.

> I disagree with you on this. A user-facing bug tracker must be welcoming
> to users, otherwise you will miss many of those bugs.

> > I have experience with 3 other issue
> > tracking systems, and none of them is significantly better in this
> > aspect; some are worse.

> Maybe we should consider some of those which are not "significantly
> better" at triaging and fixing bugs but are much better at interfacing
> with end users and occasional contributors?

What could be easier than M-x report-emacs-bug or just sending an email
to bug-gnu-emacs@gnu.org?

I run Gentoo, and for many days now a package won't build, and I want to
report it as a bug.  But I just can't face the hassle of opening
Firefox, looking up Gentoo's bugzilla address, logging on to it with a
password I've got written down somewhere, filling in numerous fields on
a screen, many of which are not relevant (but they're compulsory), then
having to return to it in order to respond to responses.  It's just too
much work.  I suppose I'll get around to it some time.

That's not to say debbugs is perfect.  But for me, it beats bugzilla and
other Web browser based trackers handsomely.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

>> Maybe we should consider some of those which are not "significantly
>> better" at triaging and fixing bugs but are much better at interfacing
>> with end users and occasional contributors?
>
> What could be easier than M-x report-emacs-bug or just sending an email
> to bug-gnu-emacs@gnu.org?

This topic was discussed several times already on this ml.

First of all, email is not configured or even available on all machines.
This forces the user to copy&paste text from Emacs to another
application (easy) or to another machine (not so easy). Attaching files
is not straightforward even when sending from Emacs itself.

After the initial report, if the user wishes to participate he must do
so by email, taking care of not altering To: and/or CC: headers. Also,
some users might have preferences about their level of partipation on
the ensuing discussion (be notified about every message, only messages
that mention him or only the message that resolves the bug). Actually,
the reporter risks being spammed by dozens of emails after a bug report
without an obvious method for stopping the flood.

> I run Gentoo, and for many days now a package won't build, and I want to
> report it as a bug.  But I just can't face the hassle of opening
> Firefox, looking up Gentoo's bugzilla address, logging on to it with a
> password I've got written down somewhere, filling in numerous fields on
> a screen, many of which are not relevant (but they're compulsory), then
> having to return to it in order to respond to responses.  It's just too
> much work.  I suppose I'll get around to it some time.
>
> That's not to say debbugs is perfect.  But for me, it beats bugzilla and
> other Web browser based trackers handsomely.

Emacs could act as an interface for some of those bug trackers,
automatically filling known fields. Instead of sending an email, it
would send an HTTPS request. It would be report-emacs-bug, but with the
advantage of being fully operational whenever the machine has access to
the WWW.

IIRC all this was discussed months ago and some of the proposed
candidates had an HTTP API that would make possible to implement a
front-end on Emacs.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Emacs could act as an interface for some of those bug trackers,
> automatically filling known fields. Instead of sending an email, it
> would send an HTTPS request. It would be report-emacs-bug, but with the
> advantage of being fully operational whenever the machine has access to
> the WWW.

Yes, that would be very nice.

> IIRC all this was discussed months ago and some of the proposed
> candidates had an HTTP API that would make possible to implement a
> front-end on Emacs.

If I remember correctly, some systems were proposed, but none had the
required interfaces as yet -- that is, being able to open/close/etc bug
reports/pull requests via a web interface, and an email interface, and
an API, all three being deemed necessary.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 17.11.2019 21:59, Lars Ingebrigtsen wrote:
> being able to open/close/etc bug
> reports/pull requests via a web interface, and an email interface, and
> an API

I'm pretty sure GitLab fits these bullet points. We even have an 
instance running already.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 17.11.2019 21:59, Lars Ingebrigtsen wrote:
>> being able to open/close/etc bug
>> reports/pull requests via a web interface, and an email interface, and
>> an API
>
> I'm pretty sure GitLab fits these bullet points.

If so, I'm all for switching.  But my impression from the huge
megathread...  was is this spring? ... was that there was a bunch of
stuff you couldn't do via email still.

> We even have an instance running already.

Is it publicly available? 

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 17.11.2019 22:09, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 17.11.2019 21:59, Lars Ingebrigtsen wrote:
>>> being able to open/close/etc bug
>>> reports/pull requests via a web interface, and an email interface, and
>>> an API
>>
>> I'm pretty sure GitLab fits these bullet points.
> 
> If so, I'm all for switching.  But my impression from the huge
> megathread...  was is this spring? ... was that there was a bunch of
> stuff you couldn't do via email still.

I'm not quite sure where the discussion stopped, actually.

Maybe the absence of an Emacs-driven UI? But it's a bar too high, if you 
ask me.

>> We even have an instance running already.
> 
> Is it publicly available?

https://emba.gnu.org/emacs/emacs/

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Maybe the absence of an Emacs-driven UI? But it's a bar too high, if
> you ask me.

If it has a sensible API, adjusting debbugs-gnu to use that API as a
backend instead of the SOAPy suds we use today shouldn't be a big deal.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 17.11.2019 22:22, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Maybe the absence of an Emacs-driven UI? But it's a bar too high, if
>> you ask me.
> 
> If it has a sensible API, adjusting debbugs-gnu to use that API as a
> backend instead of the SOAPy suds we use today shouldn't be a big deal.

Please see for yourself whether it has a sensible API:

https://docs.gitlab.com/ee/api/
https://docs.gitlab.com/ee/api/api_resources.html

(It does require authentication, though.)

And if you encounter any problems, don't hesitate to ask.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Please see for yourself whether it has a sensible API:
>
> https://docs.gitlab.com/ee/api/
> https://docs.gitlab.com/ee/api/api_resources.html

I've skimmed the documentation, and it seems sensible, and doesn't seem
to RESTful, which can be a pain (i.e., it doesn't seem like you have
to issue separate GETs for each item in a "discussion", for instance).

But it has arbitrary restrictions like

per_page 	Number of items to list per page (default: 20, max: 100)

which means that to download the 3300 open bugs in the Emacs bug tracker
you have to issue 33 of these, but whatevs.

> (It does require authentication, though.)

That's a shame.  Accessing the read-only parts of the API shouldn't
require any auth, because that means that you have to register yourself
as a user on the web site before you can look at the bugs in the Emacs
interface, which looks like a deal breaker to me.

Or perhaps it's possible to register a read-only default account that
non-registered Emacs users could use?

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 18.11.2019 10:42, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Please see for yourself whether it has a sensible API:
>>
>> https://docs.gitlab.com/ee/api/
>> https://docs.gitlab.com/ee/api/api_resources.html
> 
> I've skimmed the documentation, and it seems sensible, and doesn't seem
> to RESTful, which can be a pain (i.e., it doesn't seem like you have
> to issue separate GETs for each item in a "discussion", for instance).
> 
> But it has arbitrary restrictions like
> 
> per_page 	Number of items to list per page (default: 20, max: 100)
> 
> which means that to download the 3300 open bugs in the Emacs bug tracker
> you have to issue 33 of these, but whatevs.

I think that's normal for a public API, and 33 requests is not a lot.

>> (It does require authentication, though.)
> 
> That's a shame.  Accessing the read-only parts of the API shouldn't
> require any auth, because that means that you have to register yourself
> as a user on the web site before you can look at the bugs in the Emacs
> interface, which looks like a deal breaker to me.

Sorry, I only meant that to do some modifications you need to have a 
registered account (unlike Debbugs which just needs an email).

Public info is public: https://emba.gnu.org/api/v4/projects/1/issues

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Sorry, I only meant that to do some modifications you need to have a
> registered account (unlike Debbugs which just needs an email).
>
> Public info is public: https://emba.gnu.org/api/v4/projects/1/issues

Hm, I guess the documentation here is wrong?  "Every API call to issues
must be authenticated."  But that's good then.

https://docs.gitlab.com/ee/api/issues.html

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Mon, Nov 18, 2019 at 11:29 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > Sorry, I only meant that to do some modifications you need to have a
> > registered account (unlike Debbugs which just needs an email).
> >
> > Public info is public: https://emba.gnu.org/api/v4/projects/1/issues
>
> Hm, I guess the documentation here is wrong?

I think it is right.  A local experiment revealed that a naive GET to
'api/v4/issues' returns '401 Unauthorized'.  I might be trying with
an unsuitably configured project though, or perhaps there is
some universal public read token for these cases.

João

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 18.11.2019 13:36, João Távora wrote:
>>> Public info is public:https://emba.gnu.org/api/v4/projects/1/issues
>> Hm, I guess the documentation here is wrong?
> I think it is right.  A local experiment revealed that a naive GET to
> 'api/v4/issues' returns '401 Unauthorized'.  I might be trying with
> an unsuitably configured project though, or perhaps there is
> some universal public read token for these cases.

I mean, the above link it working without authentication.

You can also issue the same request from the console with curl. The 
project you were trying it with is probably configured as private.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Mon, Nov 18, 2019 at 12:04 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 18.11.2019 13:36, João Távora wrote:
> >>> Public info is public:https://emba.gnu.org/api/v4/projects/1/issues
> >> Hm, I guess the documentation here is wrong?
> > I think it is right.  A local experiment revealed that a naive GET to
> > 'api/v4/issues' returns '401 Unauthorized'.  I might be trying with
> > an unsuitably configured project though, or perhaps there is
> > some universal public read token for these cases.
>
> I mean, the above link it working without authentication.
>
> You can also issue the same request from the console with curl. The
> project you were trying it with is probably configured as private.

I was trying with curl.  As I suspected, my project is not configured
for this. Sorry for the noise.

João

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But it has arbitrary restrictions like
>
> per_page 	Number of items to list per page (default: 20, max: 100)
>
> which means that to download the 3300 open bugs in the Emacs bug tracker
> you have to issue 33 of these, but whatevs.

FTR, the debbugs servers have also a limitation how many bugs they
server per request. debbugs-gnu takes care, and sends proper requests
for you in the background.

Nothing new.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 17 Nov 2019 22:03:05 +0200
> Cc: emacs-devel@gnu.org
> 
> I'm pretty sure GitLab fits these bullet points. We even have an 
> instance running already.

Back then I posted a few requirements that will have to be implemented
before we will be able to switch.  AFAIK, nothing's changed since
then.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 17.11.2019 22:36, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sun, 17 Nov 2019 22:03:05 +0200
>> Cc: emacs-devel@gnu.org
>>
>> I'm pretty sure GitLab fits these bullet points. We even have an
>> instance running already.
> 
> Back then I posted a few requirements that will have to be implemented
> before we will be able to switch.  AFAIK, nothing's changed since
> then.

Do we track that list of requirements somewhere?

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> Cc: larsi@gnus.org, ofv@wanadoo.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 17 Nov 2019 22:57:51 +0200
> 
> > Back then I posted a few requirements that will have to be implemented
> > before we will be able to switch.  AFAIK, nothing's changed since
> > then.
> 
> Do we track that list of requirements somewhere?

Depends on the meaning of "track", I guess.  And on the meaning of
"we".

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 18.11.2019 5:24, Eli Zaretskii wrote:
>> Cc: larsi@gnus.org, ofv@wanadoo.es, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sun, 17 Nov 2019 22:57:51 +0200
>>
>>> Back then I posted a few requirements that will have to be implemented
>>> before we will be able to switch.  AFAIK, nothing's changed since
>>> then.
>>
>> Do we track that list of requirements somewhere?
> 
> Depends on the meaning of "track", I guess.  And on the meaning of
> "we".

OK, I found the report we filed back then: 
https://gitlab.com/gitlab-org/gitlab/issues/28152

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> OK, I found the report we filed back then:
> https://gitlab.com/gitlab-org/gitlab/issues/28152

(Adding Toon Claes to Cc as the submitter of that issue.)

From reading that page, there doesn't seem to be much progress here.
Does anyone know if any of this is being worked on?

Also, regarding some of the items on that list:

- "Diff mailing list" -- I thought this was just a commit hook run on
the server.  Can't we just add that commit hook to the repository
manually, whether or not Gitlab adds support for it or not?

- "Integration with debbugs" -- should probably be named "Migration
from debbugs".

- "Emacs frontend for bug tracker" -- is something we want, but I
don't see why we should ask Gitlab developers to work on it.  Most
likely we'll have better success adapting debbugs ourselves as has
already been suggested in this thread.

Best regards,
Stefan Kangas

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> - "Integration with debbugs" -- should probably be named "Migration
> from debbugs".

Yup.  We'll have to import the bugs from debbugs into the Gitlab issue
tracker.  Looking at the API, that should be possible, but it'll look
somewhat weird, because the style is just different: The Gitlab
discussion style is "a couple of lines of text with no quoting" while
email is more...  verbose.  But you'll have that problem anyway when you
have a hybrid web/mail submission interface.

> - "Emacs frontend for bug tracker" -- is something we want, but I
> don't see why we should ask Gitlab developers to work on it.  Most
> likely we'll have better success adapting debbugs ourselves as has
> already been suggested in this thread.

Yes.  I think if we commit to using Gitlab, then the equivalent of a
debbugs-gnu interface would appear, as if by magic, pretty quickly.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> Cc: larsi@gnus.org, ofv@wanadoo.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 18 Nov 2019 16:02:11 +0200
> 
> >> Do we track that list of requirements somewhere?
> > 
> > Depends on the meaning of "track", I guess.  And on the meaning of
> > "we".
> 
> OK, I found the report we filed back then: 
> https://gitlab.com/gitlab-org/gitlab/issues/28152

If someone is interested in my personal perspective on this, it is
here:

  https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg01061.html

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 18.11.2019 18:12, Eli Zaretskii wrote:
>> Cc: larsi@gnus.org, ofv@wanadoo.es, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Mon, 18 Nov 2019 16:02:11 +0200
>>
>>>> Do we track that list of requirements somewhere?
>>>
>>> Depends on the meaning of "track", I guess.  And on the meaning of
>>> "we".
>>
>> OK, I found the report we filed back then:
>> https://gitlab.com/gitlab-org/gitlab/issues/28152
> 
> If someone is interested in my personal perspective on this, it is
> here:
> 
>    https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg01061.html

I'd like to comment on the "few major issues" there, to summarize the 
situation as I see it.

 > main problem with Gitlab is that AFAIU it requires to do most of
the work from a Web browser

We can/should do an Emacs client. It shouldn't be too hard, at least one 
of the frequent contributors said that he'd probably work on it if we 
start migration in earnest. One major change, for users and developers: 
authentication.

 > The second major issue is with bug reports.  This is mentioned towards
the end of the issue, but it is IME much more important than merge
requests

I agree, and IMO the migration's biggest win would be in migrating to a 
new issue tracking system. Say what you want about Gitlab's problems, 
but it definitely has better capabilities for organizing bug reports 
than Debbugs (though it's a fairly low bar). The tagging system is 
there. Pinging assignees can be done using bots, which is a popular 
concept these days (basically a kind of plugin).

 > Next, it is not clear to me how will this affect my Git workflows.
Before I push a changeset, I like to build Emacs on my system, perhaps
run Emacs under a debugger and look around at relevant variables, run
some tests that I think are relevant, etc.  It sounds like with Gitlab
all that must be done remotely, on some other machine?

There's no "must" here. Gitlab has a CI, but it's like Hydra. You can 
still apply patches locally and build/test on your machine.

 > And if I want it on my machine, I will need to checkout a non-master 
branch and build it?

What else do you do when somebody pushes as scratch/*** branch for 
review? Check it out and build.

Though of course you can create a diff between revisions and apply it to 
the current tree without switching branches or making any commits.

In any case, I don't think Gitlab will have to change this part of our 
workflow much.

 > Last, but not least: the email interface.

It is important.

 > And here my admittedly limited
experience with Gitlab is abysmally bad: the one project that migrated
to Gitlab basically flooded my inbox with unimportant notifications
like assigning and reassigning issues, changing the issue's severity,
and other similar litter.

IMHO you are somewhat biased by your current experience, and 
automatically consider some notifications unimportant because you don't 
receive them in the current system.

I *think* these can be configured to a better granularity, or we have a 
good chance of it being added in a future version of Gitlab. But failing 
that, email filters are still available to use.

Speaking of "unimportant notifications", I receive a large volume of 
email these days from the bug tracker, only a small percentage of which 
is actually interesting to me. And there is no way to manage that.

 > I tried to configure the notifications, but
failed to do so (perhaps due to insufficient permissions?), and the
only thing that worked was to disable them altogether.  I think the
email interface must be very good, flexible, and powerful, if we want
to encourage migration.

I don't disagree.

On a different note, I think the chief difficulty vs the web interface 
will not be technical. We can have customizable notifications, feature 
parity, etc, but the mode of communication on Web UI bug trackers is not 
the same: people don't always quote previous messages (or when they do, 
quote them more briefly) because, in their mind, the previous message is 
so easy to read (it's displayed just above in the web interface). 
Certainly no nested quotes from preceding messages. Given the many 
complains I've already seen here about people cutting out context in 
replies, this would be exacerbated greatly. And I don't have a good 
solution for this, unfortunately. Except maybe by replacing email-based 
communication with a Emacs-based UI that mimics the Web UI in these 
respects.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

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

  > I'm pretty sure GitLab fits these bullet points. We even have an 
  > instance running already.

Would you please say concretely what you are proposing we do?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 19.11.2019 8:08, Richard Stallman wrote:
> [[[ 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. ]]]
> 
>    > I'm pretty sure GitLab fits these bullet points. We even have an
>    > instance running already.
> 
> Would you please say concretely what you are proposing we do?

Migrate to GitLab, both the bug database and the Git repository.

There are certain steps we'd have to do to prepare for such migration, 
of course. Discuss workflows, update our tooling. Probably get some more 
patches into GitLab, too.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 19 Nov 2019 13:15:33 +0200
> Cc: ofv@wanadoo.es, larsi@gnus.org, emacs-devel@gnu.org
> 
> > Would you please say concretely what you are proposing we do?
> 
> Migrate to GitLab, both the bug database and the Git repository.
> 
> There are certain steps we'd have to do to prepare for such migration, 
> of course. Discuss workflows, update our tooling. Probably get some more 
> patches into GitLab, too.

If we want to support pull requests, there are more things to do than
just the above.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If we want to support pull requests, there are more things to do than
> just the above.

I don't think our work flow has to change for pull requests.  Of course,
if somebody wants to hit the "merge pull request" button in Gitlab, they
can do that, but for most smaller pull requests, Gitlab would just email
the patch (presumably) and we can apply it locally on our machines
before pushing to the repo, just like now.

(Like you, that's the work flow I'm comfortable with, because I want to
see how Emacs behaves after applying the patch.)

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  rms@gnu.org,  ofv@wanadoo.es,
>   emacs-devel@gnu.org
> Date: Wed, 20 Nov 2019 12:15:18 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If we want to support pull requests, there are more things to do than
> > just the above.
> 
> I don't think our work flow has to change for pull requests.

Not our work, the setup for the server that will host the repositories
to which users push their changes for pull requests.

> Of course, if somebody wants to hit the "merge pull request" button
> in Gitlab, they can do that, but for most smaller pull requests,
> Gitlab would just email the patch (presumably) and we can apply it
> locally on our machines before pushing to the repo, just like now.

What you describe is not the PR workflow that people are used to.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Wed, Nov 20, 2019 at 4:27 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Of course, if somebody wants to hit the "merge pull request" button
> > in Gitlab, they can do that, but for most smaller pull requests,
> > Gitlab would just email the patch (presumably) and we can apply it
> > locally on our machines before pushing to the repo, just like now.
>
> What you describe is not the PR workflow that people are used to.

I don't think it's very far off, though.  Here's my usual workflow with
GitHub, in the hope that it helps the discussion:

In GitHub (very similar to Gitlab), I will often cherry-pick the PR's
commits, squash them, make minor adjustments to the commit
message or even the contents and then push them myself, preserving
the with the original authorship (and sometimes crediting myself as
the co-author).

To cherry-pick the PR"s commits, I just `git fetch` from a special
Git URL that references the PR's number.  In other words, there
is no clicking in the web interface required at all.

I can push my changes to master directly, but oftentimes I will
push them to the submitter's PR branch directly (when the
submitter gives me permission to do so). Again, no Web UI
is required for this (though it helps to track where things
stand at each moment, of course)

When I'm happy with the changes, I push to master. There
are some situations where GitHub detects that I merged the
contribution. For the cases where it doesn't, I sometimes include
a "Fix #PRNUMBER" line in the commit message. This ensures
it is automatically closed.

Up to this point, I have not used the Web UI at all. There is
small wrinkle though, which may or may not be important:
Github doesn't mark the PR's I merged with the "Fix
#PRNUMBER" label purple, its oficial color for a "Merged" PR.

Perhaps Gitlab could support "Merge #PRNUMBER"
as a way to manually mark purple.

From the contributor's side, I've never had anyone object or find
this confusing. I believe once the submitter sees his/her commits in
the DAG with the little avatar they know what's happening.

Also, the bug numbers in the commit message automatically
create clickable cross-references in the PR's discussion page.
(This is like if debbugs automatically sent emails to the bug
number everytime anyone composes and pushes a commit
that mentions the bug's number.)

-- 
João Távora

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 20 Nov 2019 16:53:09 +0000
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	emacs-devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> On Wed, Nov 20, 2019 at 4:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > Of course, if somebody wants to hit the "merge pull request" button
> > > in Gitlab, they can do that, but for most smaller pull requests,
> > > Gitlab would just email the patch (presumably) and we can apply it
> > > locally on our machines before pushing to the repo, just like now.
> >
> > What you describe is not the PR workflow that people are used to.
> 
> I don't think it's very far off, though.  Here's my usual workflow with
> GitHub, in the hope that it helps the discussion:

AFAIU, you described the wokflow of a developer, not of a
contributor.  I was rather talking about the latter, and mainly before
their PR is accepted and merged.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Wed, Nov 20, 2019 at 5:44 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 20 Nov 2019 16:53:09 +0000
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, Óscar Fuentes <ofv@wanadoo.es>,
> >       emacs-devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> >
> > On Wed, Nov 20, 2019 at 4:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > > Of course, if somebody wants to hit the "merge pull request" button
> > > > in Gitlab, they can do that, but for most smaller pull requests,
> > > > Gitlab would just email the patch (presumably) and we can apply it
> > > > locally on our machines before pushing to the repo, just like now.
> > >
> > > What you describe is not the PR workflow that people are used to.
> >
> > I don't think it's very far off, though.  Here's my usual workflow with
> > GitHub, in the hope that it helps the discussion:
>
> AFAIU, you described the wokflow of a developer, not of a
> contributor.  I was rather talking about the latter, and mainly before
> their PR is accepted and merged.

Well, yeah, but from the contributor's side the process is very
similar. Apart from not being able actually merge the PR
to master, he changes the PR's branch in the very same
ways as I (the developer) described in my previous email.
(Again, without ever touching the Web UI, if he/she so wishes).

João

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 20 Nov 2019 19:29:58 +0000
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	emacs-devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > AFAIU, you described the wokflow of a developer, not of a
> > contributor.  I was rather talking about the latter, and mainly before
> > their PR is accepted and merged.
> 
> Well, yeah, but from the contributor's side the process is very
> similar. Apart from not being able actually merge the PR
> to master, he changes the PR's branch in the very same
> ways as I (the developer) described in my previous email.

That branch _is_ the problem.  You don't want that to be a branch in
our upstream repository.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Wed, Nov 20, 2019 at 8:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 20 Nov 2019 19:29:58 +0000
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, Óscar Fuentes <ofv@wanadoo.es>,
> >       emacs-devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> >
> > > AFAIU, you described the wokflow of a developer, not of a
> > > contributor.  I was rather talking about the latter, and mainly before
> > > their PR is accepted and merged.
> >
> > Well, yeah, but from the contributor's side the process is very
> > similar. Apart from not being able actually merge the PR
> > to master, he changes the PR's branch in the very same
> > ways as I (the developer) described in my previous email.
>
> That branch _is_ the problem.  You don't want that to be a branch in
> our upstream repository.

Why don't you?

(with apologies if you already answered elsewhere)

It's a reasonably "cheap" thing to manipulate in Git and can
be (if we want) ephemeral. (iow even if we accept it we
don't have to integrate it with a merge commit).

As an Emacs developer, I create branches under scratch/
very frequently.  I've now started creating them under the
/scratch/joaot prefix.  The GitLab workflow could be similar
but every user could create branches in his fork of Emacs,
within the emba instance.

Thank you,
João

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 20 Nov 2019 20:12:28 +0000
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	emacs-devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > > Well, yeah, but from the contributor's side the process is very
> > > similar. Apart from not being able actually merge the PR
> > > to master, he changes the PR's branch in the very same
> > > ways as I (the developer) described in my previous email.
> >
> > That branch _is_ the problem.  You don't want that to be a branch in
> > our upstream repository.
> 
> Why don't you?

Because then anyone could push code to our main repository, even
without having write access, and we don't want to host code we didn't
eyeball in advance: it might include stuff we don't want to have
anywhere close to Emacs, or to GNU in general.

> As an Emacs developer, I create branches under scratch/
> very frequently.

You are trusted with write access to our repository, and you obtained
that trust after some initial period whereby we took a good look at
your coding and documenting practices, and made sure you are aware of
our conventions, standards, do's and dont's.  By contrast, J.R. Hacker
from out there was never subject to such scrutiny, and could make
serious mistakes, or even do something evil on purpose.

So we will need to set up a mirror repository somewhere.  the current
best idea is to host that on savannah.nongnu, I think.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Thu, Nov 21, 2019 at 2:49 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 20 Nov 2019 20:12:28 +0000
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, Óscar Fuentes <ofv@wanadoo.es>,
> >       emacs-devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> >
> > > > Well, yeah, but from the contributor's side the process is very
> > > > similar. Apart from not being able actually merge the PR
> > > > to master, he changes the PR's branch in the very same
> > > > ways as I (the developer) described in my previous email.
> > >
> > > That branch _is_ the problem.  You don't want that to be a branch in
> > > our upstream repository.
> >
> > Why don't you?
>
> Because then anyone could push code to our main repository, even
> without having write access, and we don't want to host code we didn't
> eyeball in advance: it might include stuff we don't want to have
> anywhere close to Emacs, or to GNU in general.

Right, certainly.  But in the GitLab/GitHub model, there is that
main repository, which is your duty to protect, and also
isolated from it, one for each "JR Random Hacker", a _fork_
(maybe Gitlab calls  it a "clone") that JR can randomly hack
away in.  That fork lives in the Emacs GitLab instance.  It
does take some disk space there, but that's pretty much
it as potentially unwanted impact goes.

JR's code is never merged  to the main repository without your
or some developer's explicit approval.  GitLab has a
sophisticated permissions system that states exactly what an
owner, a maintainer, a developer and a potential contributor
can do to the main repository.

The way it would most closely reflect our current model is:

* everybody can create issues (i.e. bugs) in the main
   repository
* everybody can fork the main repository
* everybody can make pull requests to the main repository.
* every developer that currently has write access can
  change and eventually merge the pull requests from
  everybody else.

We could enhance this later, of course, to reflect another
organization within developers, for example.

João

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 21.11.2019 17:00, João Távora wrote:
> But in the GitLab/GitHub model, there is that
> main repository, which is your duty to protect, and also
> isolated from it, one for each "JR Random Hacker", a_fork_
> (maybe Gitlab calls  it a "clone") that JR can randomly hack
> away in.

I wanted to say this myself, but then tried forking in EMBA. And that 
process is still stuck. So apparently forking is slow in GitLab: 
https://gitlab.com/groups/gitlab-org/-/epics/607

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Thu, Nov 21, 2019 at 3:06 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 21.11.2019 17:00, João Távora wrote:
> > But in the GitLab/GitHub model, there is that
> > main repository, which is your duty to protect, and also
> > isolated from it, one for each "JR Random Hacker", a_fork_
> > (maybe Gitlab calls  it a "clone") that JR can randomly hack
> > away in.
>
> I wanted to say this myself, but then tried forking in EMBA. And that
> process is still stuck. So apparently forking is slow in GitLab:
> https://gitlab.com/groups/gitlab-org/-/epics/607

This is a problem, as cheap forks are a cornerstone of
this model. In other words, in my view, it doesn't make
much sense to migrate to GitLab's issue tracker without
the integration with the forking system.  Presuming that
integration is similar to Github's, of course.

João

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 21.11.2019 17:09, João Távora wrote:
>> On 21.11.2019 17:00, João Távora wrote:
>>> But in the GitLab/GitHub model, there is that
>>> main repository, which is your duty to protect, and also
>>> isolated from it, one for each "JR Random Hacker", a_fork_
>>> (maybe Gitlab calls  it a "clone") that JR can randomly hack
>>> away in.
>> I wanted to say this myself, but then tried forking in EMBA. And that
>> process is still stuck. So apparently forking is slow in GitLab:
>> https://gitlab.com/groups/gitlab-org/-/epics/607
> This is a problem, as cheap forks are a cornerstone of
> this model.

We can try using it. All depends on how many such contributors we get. 
The fork is completed now, lives here as an example: 
https://emba.gnu.org/dgutov/emacs

Of course, it's not as effortless as on GitHub, unfortunately.

> In other words, in my view, it doesn't make
> much sense to migrate to GitLab's issue tracker without
> the integration with the forking system.  Presuming that
> integration is similar to Github's, of course.

I disagree, naturally. We don't have a "PR workflow" now, so we won't 
lose anything by not enabling MR functionality for casual contributors. 
The bug tracker alone is better than Debbugs from a random user's point 
of view.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 21 Nov 2019 15:00:49 +0000
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	emacs-devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > Because then anyone could push code to our main repository, even
> > without having write access, and we don't want to host code we didn't
> > eyeball in advance: it might include stuff we don't want to have
> > anywhere close to Emacs, or to GNU in general.
> 
> Right, certainly.  But in the GitLab/GitHub model, there is that
> main repository, which is your duty to protect, and also
> isolated from it, one for each "JR Random Hacker", a _fork_
> (maybe Gitlab calls  it a "clone") that JR can randomly hack
> away in.  That fork lives in the Emacs GitLab instance.  It
> does take some disk space there, but that's pretty much
> it as potentially unwanted impact goes.

I think we are miscommunicating.  Let me ask you: where do you
envision the "Emacs GitLab" will be installed? on what server?

The most appropriate one is Savannah, which will make it be hosted on
the same machine where our upstream repository lives.  And then who's
to say that such branches pushed into our GitLab are not part of
Emacs, like all the scratch branches you and others push now?

> JR's code is never merged  to the main repository without your
> or some developer's explicit approval.  GitLab has a
> sophisticated permissions system that states exactly what an
> owner, a maintainer, a developer and a potential contributor
> can do to the main repository.

That's not the real problem.  The real problem is not to make random
code appear as being part of Emacs, and part of GNU.  they are all on
the GNU Git server, right?

> * everybody can create issues (i.e. bugs) in the main
>    repository
> * everybody can fork the main repository
> * everybody can make pull requests to the main repository.
> * every developer that currently has write access can
>   change and eventually merge the pull requests from
>   everybody else.

You are thinking about technicalities, which are not the main problem
here.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Thu, Nov 21, 2019 at 3:10 PM Eli Zaretskii <eliz@gnu.org> wrote:

> I think we are miscommunicating.  Let me ask you: where do you
> envision the "Emacs GitLab" will be installed? on what server?
>
> The most appropriate one is Savannah,

Yes, I agree

> which will make it be hosted on
> the same machine where our upstream repository lives.  And then who's
> to say that such branches pushed into our GitLab are not part of
> Emacs, like all the scratch branches you and others push now?

Is that question really important? And why does it not apply
to patches as potentially absurd or as harmful as those
branches that are sitting in email bodies of the debbugs
bug tracker and the archives of lists.gnu.org?

> > JR's code is never merged  to the main repository without your
> > or some developer's explicit approval.  GitLab has a
> > sophisticated permissions system that states exactly what an
> > owner, a maintainer, a developer and a potential contributor
> > can do to the main repository.
>
> That's not the real problem.  The real problem is not to make random
> code appear as being part of Emacs, and part of GNU.

Again, regarding appearance, I think the risk of mistaking
a user's fork on an hypothetical gitlab.gnu.org server for
the work of GNU's developers is very similar to the risk
of doing the same mistake with patches sitting in
https://lists.gnu.org/archive/html/bug-gnu-emacs/.

OK, maybe "very similar" -> "only slightly higher".

But what does that risk amount to, i.e. what are
the consequences of someone making that mistake?

> they are all on the GNU Git server, right?

Yes they are.  More specifically, in the scenario I envision, (and I'm
not an expert on the matter) I think they are in the Git servers
provided by GNU's GitLab instance (or maybe a GitLab instance
specific to GNU Emacs).

João Távora

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 21 Nov 2019 15:30:01 +0000
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	emacs-devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > which will make it be hosted on
> > the same machine where our upstream repository lives.  And then who's
> > to say that such branches pushed into our GitLab are not part of
> > Emacs, like all the scratch branches you and others push now?
> 
> Is that question really important?

Yes.  Because by hosting code that violates some copyright we could
make GNU liable.  Or if someone, by mistake or malice, pushes code
that is against the GNU policies, we could make it easy for enemies of
GNU to attack and discredit GNU.  Etc. etc.

> And why does it not apply to patches as potentially absurd or as
> harmful as those branches that are sitting in email bodies of the
> debbugs bug tracker and the archives of lists.gnu.org?

Because an email message is from someone who offers us code, wheres
code on our server is already on our server, in our repository, even
if it's a fork.  Thus, people who don't understand these
technicalities could easily be convinced that we "endorsed" that code.

> But what does that risk amount to, i.e. what are
> the consequences of someone making that mistake?

In our present chaotic world, the consequences might be dire.

And I really don't understand the need for trying to do it on
Savannah, when savannah.nongnu is a good compromise that solves this
problem.  Why should anyone care on what server is this tracker
hosted?

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Thu, Nov 21, 2019 at 6:26 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > > which will make it be hosted on
> > > the same machine where our upstream repository lives.  And then who's
> > > to say that such branches pushed into our GitLab are not part of
> > > Emacs, like all the scratch branches you and others push now?
> >
> > Is that question really important?
>
> Yes.  Because by hosting code that violates some copyright we could
> make GNU liable.  Or if someone, by mistake or malice, pushes code
> that is against the GNU policies, we could make it easy for enemies of
> GNU to attack and discredit GNU.  Etc. etc.
> > And why does it not apply to patches as potentially absurd or as
> > harmful as those branches that are sitting in email bodies of the
> > debbugs bug tracker and the archives of lists.gnu.org?
> Because an email message is from someone who offers us code, wheres
> code on our server is already on our server, in our repository, even
> if it's a fork.  Thus, people who don't understand these
> technicalities could easily be convinced that we "endorsed" that code.

Regarding perception, a lot of people that have "absurd",
"ilegal", "malicious", etc. forks of other projects on GitHub,
but I don't have reasons to believe the project's canonical
repos are worried about that perception.

But indeed, GitHub is different than gitlab.mycompany.com so
maybe Richard and the FSF legal experts could
look into that.

> > But what does that risk amount to, i.e. what are
> > the consequences of someone making that mistake?
>
> In our present chaotic world, the consequences might be dire.

OK. A bit open-ended, but I really don't have the arguments
to dispute that.

> And I really don't understand the need for trying to do it on
> Savannah, when savannah.nongnu is a good compromise that solves this
> problem.  Why should anyone care on what server is this tracker
> hosted?

Oh, I didn't propose that, you did (I think?). I just assumed it
was a requirement. I personally don't care what server the
canonical fork of Emacs is in.

João

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 21 Nov 2019 19:16:05 +0000
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	emacs-devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > And I really don't understand the need for trying to do it on
> > Savannah, when savannah.nongnu is a good compromise that solves this
> > problem.  Why should anyone care on what server is this tracker
> > hosted?
> 
> Oh, I didn't propose that, you did (I think?). I just assumed it
> was a requirement. I personally don't care what server the
> canonical fork of Emacs is in.

It isn't a requirement, it's a compromise with which I think (and
hope) everyone could live, if/when we get to setting up such a
service, be it GitLab or something similar.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

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

When a GNU package is not hosted on Savannah, that creates a risk of
various kinds of problems.  Thus, we need to discourage putting GNU
package repos anywhere else.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 21.11.2019 20:26, Eli Zaretskii wrote:
> And I really don't understand the need for trying to do it on
> Savannah, when savannah.nongnu is a good compromise that solves this
> problem.  Why should anyone care on what server is this tracker
> hosted?

If the canonical Emacs development repository is on savannah.nongnu, 
wouldn't that imply that Emacs is not GNU anymore?

And that wouldn't solve any potential problems with copyright, abuse, etc.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> Cc: larsi@gnus.org, ofv@wanadoo.es, emacs-devel@gnu.org, rms@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 21 Nov 2019 22:04:50 +0200
> 
> On 21.11.2019 20:26, Eli Zaretskii wrote:
> > And I really don't understand the need for trying to do it on
> > Savannah, when savannah.nongnu is a good compromise that solves this
> > problem.  Why should anyone care on what server is this tracker
> > hosted?
> 
> If the canonical Emacs development repository is on savannah.nongnu, 
> wouldn't that imply that Emacs is not GNU anymore?

No, the canonical repository will stay on savannah.gnu.org.  Only the
repository for PRs will be on savannah.nongnu.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 22.11.2019 9:07, Eli Zaretskii wrote:
> No, the canonical repository will stay on savannah.gnu.org.  Only the
> repository for PRs will be on savannah.nongnu.

That... probably won't help much, then. There's no capability for 
creating cross-deployment PRs, that's for sure. So it would mean having 
no PR functionality for casual contributors.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> Cc: joaotavora@gmail.com, larsi@gnus.org, ofv@wanadoo.es,
>  emacs-devel@gnu.org, rms@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 22 Nov 2019 10:23:24 +0200
> 
> On 22.11.2019 9:07, Eli Zaretskii wrote:
> > No, the canonical repository will stay on savannah.gnu.org.  Only the
> > repository for PRs will be on savannah.nongnu.
> 
> That... probably won't help much, then. There's no capability for 
> creating cross-deployment PRs, that's for sure.

Sorry, I don't understand what you mean by that.  AFAIK, Git has no
problems with adding as many remotes as one likes.  The cross-server
issue will only be relevant when an authorized developer wants to
actually merge the PR, it shouldn't be an issue for (or even visible
to) the author of the PR.  Or what am I missing?

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: joaotavora@gmail.com, larsi@gnus.org, ofv@wanadoo.es,
>>  emacs-devel@gnu.org, rms@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Fri, 22 Nov 2019 10:23:24 +0200
>> 
>> On 22.11.2019 9:07, Eli Zaretskii wrote:
>> > No, the canonical repository will stay on savannah.gnu.org.  Only the
>> > repository for PRs will be on savannah.nongnu.
>> 
>> That... probably won't help much, then. There's no capability for 
>> creating cross-deployment PRs, that's for sure.
>
> Sorry, I don't understand what you mean by that.  AFAIK, Git has no
> problems with adding as many remotes as one likes.  The cross-server
> issue will only be relevant when an authorized developer wants to
> actually merge the PR, it shouldn't be an issue for (or even visible
> to) the author of the PR.  Or what am I missing?

I won't answer for Dmitry, but I think the nice diff output and
automatic cross-references, _in the Web UI_ are almost guaranteed _not_
to work cross-deployment.  But from the console it should be exactly the
same, yes.

João

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  larsi@gnus.org,  ofv@wanadoo.es,
>   emacs-devel@gnu.org,  rms@gnu.org
> Date: Fri, 22 Nov 2019 09:46:17 +0000
> 
> I think the nice diff output and automatic cross-references, _in the
> Web UI_ are almost guaranteed _not_ to work cross-deployment.  But
> from the console it should be exactly the same, yes.

I still don't think I see the problem.  "git diff" works between
branches, and the savannah.nongnu repository will be a copy of the
upstream one.  So where's the problem?

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: Dmitry Gutov <dgutov@yandex.ru>,  larsi@gnus.org,  ofv@wanadoo.es,
>>   emacs-devel@gnu.org,  rms@gnu.org
>> Date: Fri, 22 Nov 2019 09:46:17 +0000
>> 
>> I think the nice diff output and automatic cross-references, _in the
>> Web UI_ are almost guaranteed _not_ to work cross-deployment.  But
>> from the console it should be exactly the same, yes.
>
> I still don't think I see the problem.  "git diff" works between
> branches, and the savannah.nongnu repository will be a copy of the
> upstream one.  So where's the problem?

Maybe there isn't one, and I'm not seeing the full picture.

In your scenario, savannah.nongnu is the full-featured fancy-web-enabled
GitLab installation where everyone can fork at will, from the Web
UI, the console or some other UI.  Right?

Inside savannah.nongnu, there is an Emacs repo that is a very close copy
of our current upstream one.  Our current upstream one is insulated from
all the frantic JR Hacker business happening in savannah.nongnu.  Right?

This means, in my limited understanding, that the "Merge pull request"
button in the Web UI wouldn't work.  Developers have to manually use Git
tools to push to, say, git.sv.gnu.org:/srv/git/emacs.git (where our
current server lives).

The above might be a problem for some, but not me.  I think it's pretty
minor, actually.  And maybe we can convince GitLab to create a feature
that automates it, or to enable us to write a plugin, or something.

João

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: dgutov@yandex.ru,  larsi@gnus.org,  ofv@wanadoo.es,
>   emacs-devel@gnu.org,  rms@gnu.org
> Date: Fri, 22 Nov 2019 10:16:00 +0000
> 
> In your scenario, savannah.nongnu is the full-featured fancy-web-enabled
> GitLab installation where everyone can fork at will, from the Web
> UI, the console or some other UI.  Right?
> 
> Inside savannah.nongnu, there is an Emacs repo that is a very close copy
> of our current upstream one.  Our current upstream one is insulated from
> all the frantic JR Hacker business happening in savannah.nongnu.  Right?

Yes, something like that.

> This means, in my limited understanding, that the "Merge pull request"
> button in the Web UI wouldn't work.  Developers have to manually use Git
> tools to push to, say, git.sv.gnu.org:/srv/git/emacs.git (where our
> current server lives).
> 
> The above might be a problem for some, but not me.  I think it's pretty
> minor, actually.  And maybe we can convince GitLab to create a feature
> that automates it, or to enable us to write a plugin, or something.

Agreed, on both accounts.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Of course, if somebody wants to hit the "merge pull request" button
>> in Gitlab, they can do that, but for most smaller pull requests,
>> Gitlab would just email the patch (presumably) and we can apply it
>> locally on our machines before pushing to the repo, just like now.
>
> What you describe is not the PR workflow that people are used to.

The first part of the sentence does, I think?  Send a pull request, and
somebody else pushes a button in the web interface to merge it.  Which
Gitlab offers.

The latter part of that sentence is our current work flow, and is, of
course, not the pull request workflow that people are used to.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  rms@gnu.org,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Thu, 21 Nov 2019 13:24:55 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Of course, if somebody wants to hit the "merge pull request" button
> >> in Gitlab, they can do that, but for most smaller pull requests,
> >> Gitlab would just email the patch (presumably) and we can apply it
> >> locally on our machines before pushing to the repo, just like now.
> >
> > What you describe is not the PR workflow that people are used to.
> 
> The first part of the sentence does, I think?

No, because before the contributor requests to merge, he/she must
submit the PR.  And that requires interaction with GitLab (or any
other service supporting PRs).

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Of course, if somebody wants to hit the "merge pull request" button
>> >> in Gitlab, they can do that, but for most smaller pull requests,
>> >> Gitlab would just email the patch (presumably) and we can apply it
>> >> locally on our machines before pushing to the repo, just like now.
>> >
>> > What you describe is not the PR workflow that people are used to.
>> 
>> The first part of the sentence does, I think?
>
> No, because before the contributor requests to merge, he/she must
> submit the PR.  And that requires interaction with GitLab (or any
> other service supporting PRs).

Yes, that's what people are used to.  (By "people" I mean "not Emacs
developers"; perhaps that was ambiguous.  :-))

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Stefan Monnier]

Alan Mackenzie <acm@muc.de> wrote:
> That's not to say debbugs is perfect.  But for me, it beats bugzilla and
> other Web browser based trackers handsomely.

Indeed, so far I've seen only bugtrackers that suck.  Either they suck
because the only good UI is web-based (and I hate having to go through
that), or they suck because they have no good web based UI (so it's only
good for those users who use it often enough to know it).

[ For good measure, I implemented my own bugtracker-that-sucks
  (https://gitlab.com/monnier/bugit).  ]

I've heard rumors that maybe SourceHut's bug tracker may satisfy both
sides, but I haven't really tried it (and when I looked at installing it
it seemed to require too much effort on my part) so I don't yet have an
opinion on it.


        Stefan

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

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

  > That's not to say debbugs is perfect.  But for me, it beats bugzilla and
  > other Web browser based trackers handsomely.

I agree completely.  Email control of a bug tracker is the best way
for most use.

In an ideal world, our bug tracker could have good support for various
kinds of interface.  It would be good to add support for other kinds
-- but not compromise support for email.

Most contributors to Emacs do not need to use the bug tracker anyway.
WHen you need to deal with bug reports often is when you start helping
to fix problems in general rather than work on your own libraries and
add a few features.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 17 Nov 2019 20:07:12 +0100
> 
> Maybe we should consider some of those which are not "significantly
> better" at triaging and fixing bugs but are much better at interfacing
> with end users and occasional contributors?

We do.  We are not there yet.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Juanma Barranquero]

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

On Sun, Nov 17, 2019 at 8:08 PM Óscar Fuentes <ofv@wanadoo.es> wrote:

>  A user-facing bug tracker must be welcoming
> to users, otherwise you will miss many of those bugs.

That's a key point.

I know how to use debbugs, and even so I sometimes drag my feet before
reporting a bug.

I don't access e-mail from Emacs, so the very idea of M-x
report-emacs-bug + copy + switch to my web client (Gmail) + paste + deal
with the carnage is... enough of a hassle that I often just write the bug
report directly without M-x report-emacs-bug and its context info, trusting
that whomever follows the bug will know I'm using the latest release and I
generally know what I'm doing and how to report valuable information.

We have a bugtracker that is reasonably good for us, not for casual users.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Perry E. Metzger]

On Sun, 17 Nov 2019 20:45:43 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> > Debbugs is a non-starter for any project that expects interaction
> > with its user base.  
> 
> A bug tracker should first and foremost help those who work on
> triaging and fixing bugs.  I have experience with 3 other issue
> tracking systems, and none of them is significantly better in this
> aspect; some are worse.

I also work with several bug tracking systems. Let me register my
personal displeasure with debbugs. I think it's primitive,
difficult for occasional users, and lacking in features for
sophisticated users. I recognize that there's a long discussion going
on about this and I don't have that much to add that others haven't,
but I thought it would be useful to note that there's yet another
person who doesn't love debbugs.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> Date: Mon, 18 Nov 2019 11:22:39 -0500
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> I also work with several bug tracking systems. Let me register my
> personal displeasure with debbugs. I think it's primitive,
> difficult for occasional users, and lacking in features for
> sophisticated users. I recognize that there's a long discussion going
> on about this and I don't have that much to add that others haven't,
> but I thought it would be useful to note that there's yet another
> person who doesn't love debbugs.

Thanks.

FTR, I didn't say I love debbugs.  I said that I need to see a much
better system to have an incentive to switch.  I'm still looking.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Perry E. Metzger]

On Mon, 18 Nov 2019 19:04:07 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> FTR, I didn't say I love debbugs.  I said that I need to see a much
> better system to have an incentive to switch.  I'm still looking.

For standalone-ish things, there are several possibilities, but in
this day and age, I'd like to see Emacs use something like a
self-hosted instance of Gitlab (which is fully free software), in
which case, the bug tracker, pull request system, etc. are all
integrated in with the source control system and work very seamlessly
together.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[John Wiegley]

>>>>> "ÓF" == Óscar Fuentes <ofv@wanadoo.es> writes:

ÓF> Debbugs is the only user-facing bug tracker I know that requires studying
ÓF> its magic incantations to complete tasks which are trivial on any other
ÓF> system. Not to mention that, after all that studying, it still won't
ÓF> provide basic features which exist and are trivial to use elsewhere.

Just to add my 2c here: I've never encountered an actually good issue tracker.
Either it's pretty and leads to unmanagable chaos (GitHub Issues), or it's
ugly and requires undue patience and expertise, yet gives experts great
reporting and control (Jira, Bugzilla, etc).

As for debbugs, let's be politik and just say we know it isn't a modern bug
tracker. But if Eli is cranking out fixes for bugs, then I'm happy with it. If
users are getting their fingers burnt, I'd rather see if we can band-aid that
problem until we find something else that works equally well for our
developers who are pouring uncountable hours of their lives into this project.

Like it or not, they get the priority right now. Being nice to new users is
great, but until they become contributors and ease our workload, serving them
can't be the priority. The goal of Emacs isn't to win hearts and minds, it's
to be a good editor and a flagship for the FSF. If RMS decides that "flagship"
means user experience, that's one thing; if it means a truly solid code base,
that's another. Yes, both is the perfect world; but there are times when we
have to choose one over the other. For me, right now, I'd rather have one Eli
than a thousand new users who merely praise us for the excellence of our bug
reporting mechanism.

Now, I'm all for there being a group of us who care deeply about the user
experience, and who work with Eli to optimize that experience as best we can
while still keeping his workflow running smoothly. I'd be more than willing to
spend time coordinating such efforts.

To date, my own experience with debbugs is:

  1. I don't know how to close a bug.
  2. I don't know how to find the information that tells me how to close a
     bug, not without spending about 15 minutes Googling.
  3. So I e-mail Eli, "Halp, please close bug XXX".
  4. Eli, being more responsive that I ever expect a volunteer to ever be,
     closes it before the day ends.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Alan Mackenzie]

Hello, John.

Good to hear from you again.

On Mon, Nov 18, 2019 at 10:59:24 -0700, John Wiegley wrote:
> >>>>> "ÓF" == Óscar Fuentes <ofv@wanadoo.es> writes:

[ .... ]

> To date, my own experience with debbugs is:

>   1. I don't know how to close a bug.

You send email to 12345-done@debbugs.gnu.org.
                       ^^^^^

>   2. I don't know how to find the information that tells me how to close a
>      bug, not without spending about 15 minutes Googling.

And one forgets between finding out and needing to look the next time.
;-(  The canonical documentation is in etc/admin/bugtracker (from
memory).

>   3. So I e-mail Eli, "Halp, please close bug XXX".
>   4. Eli, being more responsive that I ever expect a volunteer to ever be,
>      closes it before the day ends.

All this begs the question why are bugtrackers all so bad?

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Mon, Nov 18, 2019 at 6:00 PM John Wiegley <johnw@gnu.org> wrote:

> To date, my own experience with debbugs is:
>
>   1. I don't know how to close a bug.
>   2. I don't know how to find the information that tells me how to close a
>      bug, not without spending about 15 minutes Googling.
>   3. So I e-mail Eli, "Halp, please close bug XXX".
>   4. Eli, being more responsive that I ever expect a volunteer to ever be,
>      closes it before the day ends.

M-x debbugs-gnu, a command you get when you install the debbugs
GNU ELPA package is a decent Emacs interface to doing those
things, with autocompletion, etc.  It probably requires Gnus, but
isn't Gnus (but didn't you use Gnus?) It's a bit slow IME, but not
impossibly so.

João

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[John Wiegley]

>>>>> João Távora <joaotavora@gmail.com> writes:

> M-x debbugs-gnu, a command you get when you install the debbugs GNU ELPA
> package is a decent Emacs interface to doing those things, with
> autocompletion, etc. It probably requires Gnus, but isn't Gnus (but didn't
> you use Gnus?) It's a bit slow IME, but not impossibly so.

This is really great, thank you. I actually have it installed, but also forgot
that fact after the usual amount of time between bug closings. :)

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Michael Albinus]

João Távora <joaotavora@gmail.com> writes:

> M-x debbugs-gnu, a command you get when you install the debbugs
> GNU ELPA package is a decent Emacs interface to doing those
> things, with autocompletion, etc.  It probably requires Gnus, but
> isn't Gnus (but didn't you use Gnus?) It's a bit slow IME, but not
> impossibly so.

FTR, it's customisable to use RMAIL instead. A mail backend written by
Eli, for his needs ...

Somebody wrote an mu4e debbugs-gnu mail backend, but this wasn't merged
ever to the debbugs package.

> João

Best regards, Michael.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Tue, 19 Nov 2019 08:41:13 +0100
> Cc: John Wiegley <jwiegley@gmail.com>, emacs-devel <emacs-devel@gnu.org>
> 
> FTR, it's customisable to use RMAIL instead. A mail backend written by
> Eli, for his needs ...

It's supposed to serve anyone who uses Rmail for reading email.

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 18.11.2019 19:59, John Wiegley wrote:
> Just to add my 2c here: I've never encountered an actually good issue tracker.
> Either it's pretty and leads to unmanagable chaos (GitHub Issues), or it's
> ugly and requires undue patience and expertise, yet gives experts great
> reporting and control (Jira, Bugzilla, etc).

So there are user-friendly ones, and there are ones that facilitate 
advanced workflows. And there are ones that are neither.

BTW, we have Jira at work, and it's working fine (after we've settled on 
a particular workflow and configured it appropriately). And both GitHub 
and Bugzilla don't look particularly bad to me either. Of course, 
triaging bugs is work, so it's not like we can find a solution that 
requires zero effort.

Emacs project mission (was Re: "If you're still seeing problems, please reopen." [Was: bug#25148:])

[Perry E. Metzger]

Speaking more generally than just Debbugs...

On Mon, 18 Nov 2019 10:59:24 -0700 "John Wiegley" <johnw@gnu.org>
wrote:
> Like it or not, [the Emacs developers] get the priority right
> now. Being nice to new users is great, but until they become
> contributors and ease our workload, serving them can't be the
> priority.

Unfortunately, there's a potential negative cycle here. A certain
percentage of users of free software become developers. If we start
starving ourselves of users of Emacs, we end up becoming starved of
developers for Emacs, too.

I think the goal of the Emacs project should be to produce the best
possible editing/text processing experience for hackers,
period. (Well, best possible consistent with it remaining free
software, but that goal should be implicit in everything we do in the
free software movement.)

Part of that requires that Emacs "modernize"; not in the sense of
abandoning its essential Emacsness, but in the sense of making it ever
easier to write extension code, do your productivity workflows inside
Emacs, write software with Emacs, etc.

(But I've talked about that topic better in the two talks I've given
about Emacs in recent years...)

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[dick.r.chiang]

>>>>> "PEM" == Perry E Metzger <perry@piermont.com> writes:

PEM> Speaking more generally than just Debbugs...

Yes, I've seen your talks, and am happy to see an enthused bearer of the
torch.

My criticism is that speaking in generalities as you do above is
unproductive.  I think if you actually got down to the business of making the
changes you propose (Rust conversion, first-class HTML rendering, Slack
integration, etc.), you would quickly pare your wishlist down to more incremental outcomes.

A prima fascie glance would suggest emacs's mindshare has been on the wane for
years.  But for those in-the-know, the editor remains the most efficient means of
getting things done.  Its continued success doesn't require the most young
developers, just the most sensible ones.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

"Perry E. Metzger" <perry@piermont.com> writes:

> Unfortunately, there's a potential negative cycle here. A certain
> percentage of users of free software become developers. If we start
> starving ourselves of users of Emacs, we end up becoming starved of
> developers for Emacs, too.

Indeed.  Without attracting new users (and therefore new developers),
Emacs is moribund.

Kids these days don't use email.  Have a look at all the enthusiastic
people talking about Emacs on reddit and Stackexchange -- it apparently
never occurs to many of them that it's even an option so fire off an
email to emacs-devel or use `M-x report-emacs-bug': It's just so far
outside their experience of how things work.

So I think having a modern interface for users to communicate with
developers is vital, because that is how we'll get more developers in
the long run.  The trick is finding one that also supports the way more
er seasoned developers like to work, which is (basically) the way we
work now.

It sounds like Gitlab has most of what we need, but not everything, and
there seems to be a depressing dearth of development towards that goal.
Perhaps if we committed it might make some Gitlab peeps also commit to
making this work: That is, we say "If Gitlab grows feature X, Y and Z,
then Emacs development is definitely moving to Gitlab", that might spur
some enthusiasm. 

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[John Wiegley]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I think having a modern interface for users to communicate with
> developers is vital, because that is how we'll get more developers in the
> long run. The trick is finding one that also supports the way more er
> seasoned developers like to work, which is (basically) the way we work now.

> It sounds like Gitlab has most of what we need, but not everything, and
> there seems to be a depressing dearth of development towards that goal.
> Perhaps if we committed it might make some Gitlab peeps also commit to
> making this work: That is, we say "If Gitlab grows feature X, Y and Z, then
> Emacs development is definitely moving to Gitlab", that might spur some
> enthusiasm.

I agree with you completely, Lars. As long as Richard is comfortable with us
considering GitLab, I would encourage whoever has the gumption to make this
happen to begin pursuing a scheme that is both welcoming to new users, and
friendly to the workflow of those who will actually have to use the system for
many hours each day.

If you can win over Eli, and some enthusiastic random user X from Reddit,
you've likely found a winner. GitLab seems to have good mindshare, some
flexibility, and satisfies the freedom requirements of anything we might
consider.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

John Wiegley <johnw@gnu.org> writes:

> I agree with you completely, Lars. As long as Richard is comfortable with us
> considering GitLab, I would encourage whoever has the gumption to make this
> happen to begin pursuing a scheme that is both welcoming to new users, and
> friendly to the workflow of those who will actually have to use the system for
> many hours each day.
>
> If you can win over Eli, and some enthusiastic random user X from Reddit,
> you've likely found a winner. GitLab seems to have good mindshare, some
> flexibility, and satisfies the freedom requirements of anything we might
> consider.

You need an account if you want to write a new bug report ("issue") in
Gitlab, even for public projects. No problem for Emacs developers, they
will have an account on Emacs' Gitlab stanza. But we will miss bug
reports from Emacs users, which usually have no account there.

I, for example, don't write bug reports for other projects if it
requires me to create an account first.

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 20.11.2019 10:20, Michael Albinus wrote:
> You need an account if you want to write a new bug report ("issue") in
> Gitlab, even for public projects. No problem for Emacs developers, they
> will have an account on Emacs' Gitlab stanza. But we will miss bug
> reports from Emacs users, which usually have no account there.

It has OAuth support, users could log in using an account from a number 
of popular services. So that should be a non-issue.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 20.11.2019 10:20, Michael Albinus wrote:
>> You need an account if you want to write a new bug report ("issue") in
>> Gitlab, even for public projects. No problem for Emacs developers, they
>> will have an account on Emacs' Gitlab stanza. But we will miss bug
>> reports from Emacs users, which usually have no account there.
>
> It has OAuth support, users could log in using an account from a
> number of popular services. So that should be a non-issue.

But it is still a higher burden than writing an email. (No, I don't want
to say it is a show-stopper.)

Using the Gitlab API for issues requires to create a personal access
token via the Web interface, and to use it properly. Another burden.

Yes, I'm just playing with this API from within Emacs :-)

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 20.11.2019 11:23, Michael Albinus wrote:
> But it is still a higher burden than writing an email. (No, I don't want
> to say it is a show-stopper.)

Both true. But I think authentication is an unavoidable burden anyway, 
at least if we aim to target a larger audience. More ease of use = more 
possibilities for abuse as well.

> Using the Gitlab API for issues requires to create a personal access
> token via the Web interface, and to use it properly. Another burden.

I don't think the majority of bug reporters would use this approach, to 
be honest.

> Yes, I'm just playing with this API from within Emacs:-)

Cool.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> Using the Gitlab API for issues requires to create a personal access
>> token via the Web interface, and to use it properly. Another burden.
>
> I don't think the majority of bug reporters would use this approach,
> to be honest.

How shall it be possible to write an Emacs bug then, given we would have
switched from Debbugs to Gitlab issues? Only via the Gitlab Web Page?

This I would regard as a show-stopper, if Emacs does not offer a simple
method to write a bug report on its own.

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 20.11.2019 11:51, Michael Albinus wrote:

> How shall it be possible to write an Emacs bug then, given we would have
> switched from Debbugs to Gitlab issues? Only via the Gitlab Web Page?

We can have different methods (like we do already), but the easiest one 
would be to open a New Issue web page pre-filled with the user's system 
information, Emacs version, etc.

Those who went through with creating a personal access token could use 
the full-Emacs method.

> This I would regard as a show-stopper, if Emacs does not offer a simple
> method to write a bug report on its own.

Having users report bugs like they do for every other free software 
project under the sun? Oh horror.

Anyway, we could also have an special email address that would 
automatically create bugs under a dedicated account. But the user would 
have no way to edit it afterwards.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Anyway, we could also have an special email address that would
> automatically create bugs under a dedicated account. But the user
> would have no way to edit it afterwards.

Or we set it on our wishlist for Gitlab. It shall be possible to create
a new issue, or a comment for a given issue, without having an
account. For public projects, of course.

Retrieving issues from public Gitlab projects does not require
authentication, according to my plays with the Gitlab API.

Another wish from me would be extended searching. It seems, you can
search only in the title and description of issues, and NOT in the
comments.

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[João Távora]

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

On Wed, Nov 20, 2019, 10:35 Dmitry Gutov <dgutov@yandex.ru> wrote:

> Anyway, we could also have an special email address that would
> automatically create bugs under a dedicated account. But the user would
> have no way to edit it afterwards.
>

Never mind editing, that unregistered use would have no way to participate
in the discussion.

What were could do is to have the server of that special email address also
forward and relay communications to and from the user to the bugs that he
created or that he participated in. IOW change the backend of the current
debbugs email addresses.

In principle (I admit I haven't fully thought this through) this should
coexist nicely with the interactions from reagistered Gitlab users,
developers or not.

Just a thought,
João

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > Both true. But I think authentication is an unavoidable burden anyway, 
  > at least if we aim to target a larger audience.

Why do we _want_ to "target a larger audience" for bug tracking
in particular.

Sure, all else being equal we would prefer to offer more
convenient interfaces.  But is that such an imperative
that we would want to pay a price for it?  I am skeptical.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 21.11.2019 5:06, Richard Stallman wrote:
> [[[ 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. ]]]
> 
>    > Both true. But I think authentication is an unavoidable burden anyway,
>    > at least if we aim to target a larger audience.
> 
> Why do we _want_ to "target a larger audience" for bug tracking
> in particular.

The larger audience I meant here are the existing users of Emacs. A lot 
of which avoid reporting bugs to Debbugs. And I know that because I 
maintain some third-party packages with different issue trackers.

> Sure, all else being equal we would prefer to offer more
> convenient interfaces.  But is that such an imperative
> that we would want to pay a price for it?  I am skeptical.

Is hearing from all our users an imperative? I don't know. But we'd 
certainly something we'd like to have.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > The larger audience I meant here are the existing users of Emacs. A lot 
  > of which avoid reporting bugs to Debbugs. And I know that because I 
  > maintain some third-party packages with different issue trackers.

Maybe some of the people who report bugs for other packages might
avoid reporting bugs for Emacs.  If so, could you ask them why they
avoid it?

The recommended way to report one does not involve using Debbugs directly.
It is M-x report-emacs-bug.

Do they not know about report-emacs-bug?
Is there some practical obstacle for using that?
Do they have some other kind of reason?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Maybe some of the people who report bugs for other packages might
> avoid reporting bugs for Emacs.  If so, could you ask them why they
> avoid it?

I encounter this issue regularly -- people have some issue with Emacs
and I say (via email, irc, in person, even): "Well, that sounds like a
bug.  You should report it with M-x report-emacs-bug".  But they don't,
and my impression is that it seems scary.  The report seems to go into
an official secret place or something?

People are used to web-based bug trackers, and those aren't scary,
because people are used to put all kinds of nonsense on the web, while
email is for serious business.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Yuri Khan]

On Fri, 22 Nov 2019 at 19:30, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> > Maybe some of the people who report bugs for other packages might
> > avoid reporting bugs for Emacs.  If so, could you ask them why they
> > avoid it?
>
> I encounter this issue regularly -- people have some issue with Emacs
> and I say (via email, irc, in person, even): "Well, that sounds like a
> bug.  You should report it with M-x report-emacs-bug".  But they don't,
> and my impression is that it seems scary.  The report seems to go into
> an official secret place or something?

It is not scary per se; for me, it just creates an impression that it
has no way of working.

It looks as if it’s going to send an email. But I know that, in order
to be able to send email, a program has to know the SMTP server
address, the user name, and the password, and I know I haven’t
provided these to Emacs. (Definitely not to ‘emacs -Q’ in any case.)
Therefore, I conclude that Emacs is not going to be able to send email
on its own.

I also understand that Emacs could use a system facility for sending
email if there was one; but I know I haven’t configured an MTA
locally, don’t want to, and ain’t going to. So I assume Emacs is not
going to be able to delegate sending the email to any other program.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > I also understand that Emacs could use a system facility for sending
  > email if there was one; but I know I haven’t configured an MTA
  > locally, don’t want to, and ain’t going to. So I assume Emacs is not
  > going to be able to delegate sending the email to any other program.

Let's see if this problem is real or apparent.
Would you please try report-emacs-bug and see what happens?
Does it actually send the email?

If it is a real problem, the only way to make this better
is to make a better way to transmit the bug report.
What could that be?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Yuri Khan]

On Sat, 23 Nov 2019 at 20:14, Richard Stallman <rms@gnu.org> wrote:
>
> [[[ 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. ]]]
>
>   > I also understand that Emacs could use a system facility for sending
>   > email if there was one; but I know I haven’t configured an MTA
>   > locally, don’t want to, and ain’t going to. So I assume Emacs is not
>   > going to be able to delegate sending the email to any other program.
>
> Let's see if this problem is real or apparent.
> Would you please try report-emacs-bug and see what happens?
> Does it actually send the email?

$ emacs -Q
M-x report-emacs-bug

Observed behavior:

0. A prompt appears in the minibuffer: “Bug Subject:”. I enter “test”.

1. Two windows appear. The one above looks like an email message
composition window, with a bogus From email address ending in
.i-did-not-set--mail-host-address--so-tickle-me. The one below
explains:

    While in the mail buffer:

      Type C-c C-c to send the bug report.
      Type C-x k RET to cancel (don’t send it).
      Type C-c M-i to copy text to your preferred mail program.

      Type C-c TAB to visit in Info the Emacs Manual section
        about when and how to write a bug report, and what
        information you should include to help fix the bug.

If I press C-c M-i at this point, I get to step 4 below.

If I adjust my email address in the From line, compose a message text,
and press C-c C-c:

2. A prompt appears in the minibuffer, asking me “Send this bug report
to the Emacs maintainers? (yes or no). I enter “yes” RET.

3. An *Emacs Mail Setup Help* buffer explains that Emacs is not
configured to send mail, and offers three choices: ‘mail client’
(default), ‘transport’, and ‘smtp’. I press RET to choose the default
method.

4. Because I normally use Gmail via its web interface, my mail client
is _also_ unconfigured. So a Thunderbird account setup wizard appears,
asking me for an email address, SMTP server, and user name. I provide
all that and click “Finish”.

5. A Thunderbird message composer window appears, with the copy of the
bug text in the body, addressed to bug-gnu-emacs@gnu.org. At this
point I’m fairly confident that if I were to hit “Send” it would
actually go off.


So yes, it works, if the user is reasonably serious about reporting the bug.

To boost the user’s confidence in being able to send a bug report, it
might make sense to detect that Emacs is not configured to send mail
earlier, and, at step 1, add a clause to the help message:

-      Type C-c C-c to send the bug report.
+      Type C-c C-c to send the bug report.  You will be asked
+        to enter your mail server settings.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > So yes, it works, if the user is reasonably serious about reporting the bug.

Nonetheless, your report shows that the procedure is complex.
(Thanks for the detailed report.)
Some people might be put off by that and might not go through with it.

Can we come up with ways to simplify this in some usual cases?

  > To boost the user’s confidence in being able to send a bug report, it
  > might make sense to detect that Emacs is not configured to send mail
  > earlier, and, at step 1, add a clause to the help message:

  > -      Type C-c C-c to send the bug report.
  > +      Type C-c C-c to send the bug report.  You will be asked
  > +        to enter your mail server settings.

I agree that would be good.

  >  and offers three choices: ‘mail client’
  > (default), ‘transport’, and ‘smtp’.

  > 4. Because I normally use Gmail via its web interface, my mail client
  > is _also_ unconfigured.

Could we make things substantially easier by adding an option 'webmail'?
It might be able to reconize various webmail sites, and DTRT for each one.
Users could implement more of them.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[HaiJun Zhang]

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

在 2019年11月24日 +0800 AM7:06，Richard Stallman <rms@gnu.org>，写道：
[[[ 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. ]]]

So yes, it works, if the user is reasonably serious about reporting the bug.

Nonetheless, your report shows that the procedure is complex.
(Thanks for the detailed report.)
Some people might be put off by that and might not go through with it.

Can we come up with ways to simplify this in some usual cases?

To boost the user’s confidence in being able to send a bug report, it
might make sense to detect that Emacs is not configured to send mail
earlier, and, at step 1, add a clause to the help message:

- Type C-c C-c to send the bug report.
+ Type C-c C-c to send the bug report. You will be asked
+ to enter your mail server settings.

I agree that would be good.

and offers three choices: ‘mail client’
(default), ‘transport’, and ‘smtp’.

4. Because I normally use Gmail via its web interface, my mail client
is _also_ unconfigured.

Could we make things substantially easier by adding an option 'webmail'?
It might be able to reconize various webmail sites, and DTRT for each one.
Users could implement more of them.

I would like to have a GNU account. The account can be registered on a GNU web page or in emacs. The account name will be my email(the value of user-email-address).

The account can be used to report bugs, login the web page to see my reported bugs, and more.

We can define a new protocol for report-emacs-bug to use. The protocol includes:

  1.  Login with an account
  2.  Send bug report



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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Sergey Organov]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > I also understand that Emacs could use a system facility for sending
>   > email if there was one; but I know I haven’t configured an MTA
>   > locally, don’t want to, and ain’t going to. So I assume Emacs is not
>   > going to be able to delegate sending the email to any other program.

[...]

> If it is a real problem, the only way to make this better
> is to make a better way to transmit the bug report.
> What could that be?

Dedicated Emacs bug reporting WWW page (wizard) where one is instructed
to copy-paste result of M-x report-emacs-bug, or click "Send" to send a
local file got from imaginary M-x save-bug-report, the resulting actual
report being CC'd back to the author (maybe as an option). It could have
other options as well, e.g. "Mail" button, to get back to user preferred
mail client.

I find reporting bugs to be indeed somewhat complicated, and maybe even
more complicated when one does use Emacs for mail. Here is my recent
use-case.

I do use Emacs (GNUS) for all the mail and news handling, so I do have
nice working mail configuration for Emacs. Nevertheless, to actually
file a bug report I recently needed to:

1. In my usual Emacs session I encountered a (non-critical) bug. I still
worked for a while on unrelated things, and then decided to report the
bug. How? Googled for "emacs report bug" (in Firefox). Found
report-emacs-bug. Nice! (Could have used M-x apropos-command, but
googling is rather the first thing that comes to mind nowadays).

2. M-x report-emacs-bug. Entered subject at "Bug subject:" prompt, and
then mail buffer with correct credentials appeared, and there it asks to
reproduce the problem from "emacs -Q". Besides, after careful
inspection, 2 pages down the 5 pages of automatically generated content,
the report had suspect "Recent input:" section that contained irrelevant
recent input[1].

3. Decided to start "emacs -Q", but first decided to exit current emacs
instance to avoid interference with fresh session, just in case. Exited
emacs.

4. Started "emacs -Q", reproduced the problem, and thought that probably
I actually need to report-emacs-bug from here, to have more relevant
information, including "Recent input:" section.

5. M-x report-emacs-bug again, now in this "emacs -Q" instance, entered
the same "Bug subject:" again, and got another somewhat similar mail
buffer. Entered problem description (having slight inconveniences from
lacking some of my custom key-bindings), and finally ready to send...

6. Then I guessed "emacs -Q" may be misconfigured for mail sending, as I
never aimed to achieve such a goal. In addition I figured I'd rather
like the report to be sent from my usual GNUS configuration, for the
message to be logged in my local group(s) suitable for it. So I didn't
try to send the report from here.

7. Yet again I wanted to exit this instance to run my usual Emacs
session, so I saved report content to a file and exited Emacs.

8. Started fresh Emacs as I usually do, M-x gnus, M-x report-emacs-bug
the third time, entered fake subject. Replaced bug report body and
subject with that from the file saved in (7), and now I'm ready to send.

9. Hit C-c C-c to finally send the report.

Now suppose that at (1) I've had directed to Emacs bug reporting page
that said: run "emacs -Q", reproduce the problem, run M-x
emacs-report-bug, and then copy-paste the resulting buffer contents
here. How much more simple it could have been!

[1] I think that either "Recent input:" shouldn't be included, or a
warning to check the report for possible sensitive information should be
put at the beginning.

-- Sergey

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

> I encounter this issue regularly -- people have some issue with Emacs
> and I say (via email, irc, in person, even): "Well, that sounds like a
> bug.  You should report it with M-x report-emacs-bug".  But they don't,
> and my impression is that it seems scary.  The report seems to go into
> an official secret place or something?

FWIW -

When an Emacs question or answer on Stack Exchange
or Stack Overflow seems to point to a possible bug
or enhancement request, I often suggest that the
person report it using `M-x report-emacs-bug'.

And most of the time they do.  My impression is
that many might not have been previously aware of
`report-emacs-bug'.

My impression is also that those who used it for the
first time had no problem doing so.  IOW, it has not
seemed to me that it was scary of difficult to
figure out, or that they hesitated for some reason.

I believe that those Q&A sites get all kinds of
Emacs users, including many who are newbies and many
who are young and might be more used to web-based
bug reporting.  I haven't noticed any balking at
sending an email via `M-x report-emacs-bug'.

Just an impression and anecdotal info.  And I can't
speak for any who might not have filed a bug.  At
least I don't recall anyone expressing hesitation
or reporting any difficulty.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Drew Adams wrote:

> My impression is also that those who used it
> for the first time had no problem doing so.
> IOW, it has not seemed to me that it was
> scary of difficult to figure out, or that
> they hesitated for some reason.

The first time it is while not exactly "scary"
a little discomforting because I didn't even
understand it was an e-mail being composed (and
I was even an Rmail or Gnus user at the time,
but it didn't look like an ordinary message
buffer somehow), I wasn't sure to whom it was
supposed to be sent, and the insertion of data
to describe my current state felt like I was
throwing in my clothes and bike in the bargain.

Maybe one could insert a line like this: "This
is an ordinary e-mail which contains harmless
data. If you are unsure if whether to send this
or not, you are encouraged to do so."

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > Maybe one could insert a line like this: "This
  > is an ordinary e-mail which contains harmless
  > data. If you are unsure if whether to send this
  > or not, you are encouraged to do so."

Would you like to try running M-x report-emacs-bug,
and editing the buffer until it looks less "scary",
and show us the edited text?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Richard Stallman wrote:

>> Maybe one could insert a line like this:
>> "This is an ordinary e-mail which contains
>> harmless data. If you are unsure if whether
>> to send this or not, you are encouraged to
>> do so."
>
> Would you like to try running M-x
> report-emacs-bug, and editing the buffer
> until it looks less "scary", and show us the
> edited text?

While in the mail buffer:

  Type M-x message-send-and-exit to send the bug report.
  Type M-x kill-buffer RET to cancel (don’t send it).

  Type C-c TAB to visit in Info the Emacs Manual section
    about when and how to write a bug report, and what
    information you should include to help fix the bug.

  NOTE: If you are unsure whether to send the
        mail or not you are encouraged to
        do it.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

Are you suggesting we replace the text

  Type C-c C-c to send the bug report.
  Type C-x k RET to cancel (don’t send it).

  Type C-c TAB to visit in Info the Emacs Manual section
    about when and how to write a bug report, and what
    information you should include to help fix the bug.

which currently appears in *Bug Help*
with thix text?

  Type M-x message-send-and-exit to send the bug report.
  Type M-x kill-buffer RET to cancel (don’t send it).

  Type C-c TAB to visit in Info the Emacs Manual section
    about when and how to write a bug report, and what
    information you should include to help fix the bug.

  NOTE: If you are unsure whether to send the
        mail or not you are encouraged to
        do it.

You replaced a couple of key bindings with M-x commands.
Was that intentional?  Is that part the change you are suggesting?

You also added

  NOTE: If you are unsure whether to send the
        mail or not you are encouraged to
        do it.

I suppose that is part of the change you are suggesting, right?
-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Richard Stallman wrote:

> Are you suggesting we replace the text
>
>   Type C-c C-c to send the bug report.
>   Type C-x k RET to cancel (don’t send it).
>
>   Type C-c TAB to visit in Info the Emacs Manual section
>     about when and how to write a bug report, and what
>     information you should include to help fix the bug.
>
> which currently appears in *Bug Help* with
> thix text?
>
>   Type M-x message-send-and-exit to send the bug report.
>   Type M-x kill-buffer RET to cancel (don’t send it).
>
>   Type C-c TAB to visit in Info the Emacs Manual section
>     about when and how to write a bug report, and what
>     information you should include to help fix the bug.
>
>   NOTE: If you are unsure whether to send the
>         mail or not you are encouraged to
>         do it.
>
> You replaced a couple of key bindings with
> M-x commands. Was that intentional? Is that
> part the change you are suggesting? I suppose
> that is part of the change you are
> suggesting, right?

To me the M-x commands appear so that perhaps
has changed into the key bindings in some
recent Emacs version. I'm on

GNU Emacs 25.1.1 (arm-unknown-linux-gnueabihf,
GTK+ Version 3.22.11) of 2017-09-16, modified
by Debian

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Sergey Organov]

Emanuel Berg via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Drew Adams wrote:
>
>> My impression is also that those who used it
>> for the first time had no problem doing so.
>> IOW, it has not seemed to me that it was
>> scary of difficult to figure out, or that
>> they hesitated for some reason.
>
> The first time it is while not exactly "scary"
> a little discomforting because I didn't even
> understand it was an e-mail being composed (and
> I was even an Rmail or Gnus user at the time,
> but it didn't look like an ordinary message
> buffer somehow), I wasn't sure to whom it was
> supposed to be sent, and the insertion of data
> to describe my current state felt like I was
> throwing in my clothes and bike in the bargain.
>
> Maybe one could insert a line like this: "This
> is an ordinary e-mail which contains harmless
> data. If you are unsure if whether to send this
> or not, you are encouraged to do so."

Except it has "Recent input:" section 2 pages down the report that may
contain sensitive data?

-- Sergey

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Sergey Organov wrote:

>> The first time it is while not exactly
>> "scary" a little discomforting because
>> I didn't even understand it was an e-mail
>> being composed (and I was even an Rmail or
>> Gnus user at the time, but it didn't look
>> like an ordinary message buffer somehow),
>> I wasn't sure to whom it was supposed to be
>> sent, and the insertion of data to describe
>> my current state felt like I was throwing in
>> my clothes and bike in the bargain.
>> Maybe one could insert a line like this:
>> "This is an ordinary e-mail which contains
>> harmless data. If you are unsure if whether
>> to send this or not, you are encouraged to
>> do so."
>
> Except it has "Recent input:" section 2 pages
> down the report that may contain
> sensitive data?

Still, I don't think they will harm anyone...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > > Except it has "Recent input:" section 2 pages
  > > down the report that may contain
  > > sensitive data?

  > Still, I don't think they will harm anyone...

On some occasions, it might do harm.

I have two ideas for changes:

* Ask whether to include this part.

* Inform people that they could delete it if they don't
want it posted to the bug tracker.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

>   > > Except it has "Recent input:" section 2
>   > > pages down the report that may contain
>   > > sensitive data?
> 
>   > Still, I don't think they will harm anyone...
> 
> On some occasions, it might do harm.
> 
> I have two ideas for changes:
> * Ask whether to include this part.
> * Inform people that they could delete it if
>   they don't want it posted to the bug tracker.

Or offer the choice - via an option.

For the second one, maybe provide a key that
deletes that info, as opposed to making users
find, select, and delete it.

---

FWIW, 7 years ago I wrote some simple extensions
to `emacsbug.el', which I use and make available
as `emacsbug+.el'.

(I suggested such extensions for Emacs, but there
was no interest.)

1. There's an option that lets you choose which
   fields to include by default, when reporting
   a bug: `ebp-report-emacs-bug-included-fields'.

2. There are individual commands to insert each of
   the various fields, so you can easily include
   any that you don't choose to include by default.
   Most are bound to keys with prefix `c-o'.

   `ebp-insert-all'
   `ebp-insert-features'          (`C-o f')
   `ebp-insert-load-path-shadows' (`C-o l')
   `ebp-insert-major-mode'        (`C-o j')
   `ebp-insert-minor-modes'       (`C-o n')
   `ebp-insert-recent-input'      (`C-o i')
   `ebp-insert-recent-messages'   (`C-o m')
   `ebp-insert-settings'          (`C-o s')
   `ebp-insert-version'

`emacsbug+.el' is here:

https://www.emacswiki.org/emacs/download/emacsbug%2b.el

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> > I have two ideas for changes:
> > * Ask whether to include this part.
> > * Inform people that they could delete it if
> >   they don't want it posted to the bug tracker.
>
> Or offer the choice - via an option.

I don't think this is a good fit for an option, since whether or not
to include this data or not will be highly situational.

> 2. There are individual commands to insert each of>    the various fields, so you can easily include
>    any that you don't choose to include by default.
>    Most are bound to keys with prefix `c-o'.
>
>    `ebp-insert-all'
>    `ebp-insert-features'          (`C-o f')
>    `ebp-insert-load-path-shadows' (`C-o l')
>    `ebp-insert-major-mode'        (`C-o j')
>    `ebp-insert-minor-modes'       (`C-o n')
>    `ebp-insert-recent-input'      (`C-o i')
>    `ebp-insert-recent-messages'   (`C-o m')
>    `ebp-insert-settings'          (`C-o s')
>    `ebp-insert-version'

That seems like more typing (and remembering) than I'd prefer.  If we
want to do something like this, my ideal would be closer to how magit
handles chunks: 'n' to go to next, 'k' to kill it.

To elaborate, let's say I move point outside the "body text" part of
the bug report, on top of the auto generated data.  Here, the current
"block" (as detailed above: features, load-path-shadows, major-mode,
etc.) gets highlighted, and the keys no longer does
self-insert-comand, but instead the commands:

 'n' move to next block
 'p' move to previous block
 'e' edit current block (make "block" into regular text, disabling commands)
 'k' kill current block

Even better if you see a help text in the minibuffer when point is on
these blocks.

Just an idea.  Not sure if it's worth implementing, but I think it
would be useful.

Best regards,
Stefan Kangas

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

> > 2. There are individual commands to insert each of>    the various
> fields, so you can easily include
> >    any that you don't choose to include by default.
> >    Most are bound to keys with prefix `C-o'.
> 
> That seems like more typing (and remembering) than I'd prefer.  If we
> want to do something like this, my ideal would be closer to how magit
> handles chunks: 'n' to go to next, 'k' to kill it.

#1, which you didn't quote, was the main thing.

The idea is that a user will typically want the
same fields to be included/excluded for her bug
reports.

In that case there's rarely any need to do anything
(hit a key to include, or kill text to exclude it).

The keys to include specific sections are available
for the rare case when you might want to include
something you generally exclude (via the option).

And `C-h m' tells you about the keys - there's
really nothing to remember.  Using such a key would
be relatively rare, in which case `C-h m' is your
friend.

> To elaborate, let's say I move point outside the "body text" part of
> the bug report, on top of the auto generated data.  Here, the current
> "block" (as detailed above: features, load-path-shadows, major-mode,
> etc.) gets highlighted, and the keys no longer does
> self-insert-comand, but instead the commands:
> 
>  'n' move to next block
>  'p' move to previous block
>  'e' edit current block (make "block" into regular text, disabling
> commands)
>  'k' kill current block
> 
> Even better if you see a help text in the minibuffer when point is on
> these blocks.
> 
> Just an idea.  Not sure if it's worth implementing, but I think it
> would be useful.

Good.  All ideas are helpful.

I think it's generally better to let users
define the typical, general behavior they want.

That's better than always including everything
(a hard-coding the behavior) and then giving
users ways to navigate and kill included text.
Why make users do that?

IOW, instead of making users kill the same kind
of text over and over, each time they file a
bug, let them choose their own preferred
(default) reporting behavior.

The default value of the option I provided does
include everything (all fields) - we ask for it
for a reason.  But a user can provide her own
default behavior by customizing the option.

For example, a user might change the default
behavior, to include only the Emacs _version_.

Because there's a command (and key) for each
section, she can easily override her default
behavior whenever including something more
makes sense to her.

Because I split the included text into separate
pieces (categories/fields), the code is a bit
cleaner, and users have better control over the
behavior.  Likewise, any code that wants to
tweak or make use of the basic code.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > 1. There's an option that lets you choose which
  >    fields to include by default, when reporting
  >    a bug: `ebp-report-emacs-bug-included-fields'.


This would be extra complication, the opposite of what we want in general.

The specific problem here is that report-emacs-bug includes data that
might be sensitive.  It would be good to remind people that they don't
have to send that data, and help them avoid it if/when they want to.
But let's do that in the simplest possible way.

I think the simplest possible way is to identify the data that might
be sensitive, and help users exclude all that data.




-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> The specific problem here is that report-emacs-bug includes data that
> might be sensitive.  It would be good to remind people that they don't
> have to send that data, and help them avoid it if/when they want to.
> But let's do that in the simplest possible way.

The "Recent messages" bit in the bug reports is a bomb just waiting to
blow up.  At some point somebody will be doing some mining of the bug
repo for "interesting" messages and do a write-up of how horribly lax
the GNU project it with people's privacy.

And they'd be correct: I think including that bit in the bug report is
indefensible.  (Not to mention useless.)

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

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

> The "Recent messages" bit in the bug reports is a bomb just waiting to
> blow up.  At some point somebody will be doing some mining of the bug
> repo for "interesting" messages and do a write-up of how horribly lax
> the GNU project it with people's privacy.
> 
> And they'd be correct: I think including that bit in the bug report is
> indefensible.  (Not to mention useless.)

If this is judged to be extremely serious, then the
default value of the option I proposed could be flipped,
so that by default nothing (other than, say, the Emacs
version) is included.

I made the default behavior include everything, because
I thought that (1) that would be more acceptable, and
it is backward-compatible, and (2) it is presumably
most helpful for bug fixers, by providing more info.

But there's no problem changing the default to include
nothing user-oriented, or even nothing at all.  That's
a decision for Emacs to make.  What to _actually_ 
include by default should be decidable by an individual
user.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 27 Nov 2019 12:38:30 +0100
> Cc: moasenwood@zoho.eu, Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> The "Recent messages" bit in the bug reports is a bomb just waiting to
> blow up.

You did read Glenn's message, where he reminds us that we removed this
part in Emacs 24.5, yes?

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> The "Recent messages" bit in the bug reports is a bomb just waiting to
>> blow up.
>
> You did read Glenn's message, where he reminds us that we removed this
> part in Emacs 24.5, yes?

No, what we removed in 24.5 was "recent keystrokes".  We still have
"recent messages".

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rms@gnu.org,  moasenwood@zoho.eu,  drew.adams@oracle.com,
>   emacs-devel@gnu.org
> Date: Wed, 27 Nov 2019 17:16:39 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The "Recent messages" bit in the bug reports is a bomb just waiting to
> >> blow up.
> >
> > You did read Glenn's message, where he reminds us that we removed this
> > part in Emacs 24.5, yes?
> 
> No, what we removed in 24.5 was "recent keystrokes".  We still have
> "recent messages".

Sounds like we will gradually remove every detail of the bug report.
Why not remove the command entirely, then?  Let's release Emacs 27
without it.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Sounds like we will gradually remove every detail of the bug report.
> Why not remove the command entirely, then?  Let's release Emacs 27
> without it.

I don't think that's a very constructive response.

You obviously thought that Emacs didn't include the "recent messages"
bit now, by which I can only assume that you, like me, never look at
that portion of the bug reports.  So we've already established that it
has zero utility, so why should we include that particular
very problematic (from a privacy standpoint) part in the bug reports?

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Stefan Kangas]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The "Recent messages" bit in the bug reports is a bomb just waiting to
> blow up.  At some point somebody will be doing some mining of the bug
> repo for "interesting" messages and do a write-up of how horribly lax
> the GNU project it with people's privacy.

I agree.  We should not automatically include potentially sensitive
user data in bug reports.  We can ask for it in the (presumably rare)
cases when we do need to see those messages.

How about the attached patch?

Best regards,
Stefan Kangas

[-- Attachment #2: 0001-Don-t-include-section-Recent-messages-in-bug-reports.patch --]
[-- Type: text/x-patch, Size: 1436 bytes --]

From 0a7c40cc6f126e8aa57c5d78a9ae595d5dc57445 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Thu, 28 Nov 2019 10:30:30 +0100
Subject: [PATCH] Don't include section "Recent messages" in bug reports

* lisp/mail/emacsbug.el (report-emacs-bug): Don't include "Recent
messages" since it has privacy implications.
Problem reported by Lars Ingebrigtsen in:
https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg01099.html
---
 lisp/mail/emacsbug.el | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/lisp/mail/emacsbug.el b/lisp/mail/emacsbug.el
index 1c2f11680b..61840be95c 100644
--- a/lisp/mail/emacsbug.el
+++ b/lisp/mail/emacsbug.el
@@ -320,18 +320,6 @@ report-emacs-bug
     (let ((os (ignore-errors (report-emacs-bug--os-description))))
       (if (stringp os)
           (insert "System Description: " os "\n\n")))
-    (let ((message-buf (get-buffer "*Messages*")))
-      (if message-buf
-	  (let (beg-pos
-		(end-pos message-end-point))
-	    (with-current-buffer message-buf
-	      (goto-char end-pos)
-	      (forward-line -10)
-	      (setq beg-pos (point)))
-            (terpri (current-buffer) t)
-	    (insert "Recent messages:\n")
-	    (insert-buffer-substring message-buf beg-pos end-pos))))
-    (insert "\n")
     (when (and system-configuration-options
 	       (not (equal system-configuration-options "")))
       (insert "Configured using:\n 'configure "
-- 
2.20.1

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

> > The "Recent messages" bit in the bug reports is a bomb just waiting
> > to blow up.  At some point somebody will be doing some mining of the bug
> > repo for "interesting" messages and do a write-up of how horribly lax
> > the GNU project it with people's privacy.
> 
> I agree.  We should not automatically include potentially sensitive
> user data in bug reports.  We can ask for it in the (presumably rare)
> cases when we do need to see those messages.
> 
> How about the attached patch?

It's not just about "Recent messages".  It's about
anything we automatically insert into the report,
which a user might not pay attention to, or even if
she does, which she might not want to send.

Let users decide.  A simple option takes care of
this.  And separating the parts of the code that
insert each different part of the automatic info
means that we can also give users commands to
insert any of them as one-offs, to override their
chosen default preferred behavior.

I see no reason why we wouldn't want to let users
decide, in this regard - whether it's about privacy
or any other reason a user might have for her
preference.

What's the difficulty or downside to doing this?

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > Let users decide.  A simple option takes care of
  > this.

Please don't be so doctrinaire.  It is not immediately obvious what
interface is best to help various users with various situations ask
for what is best for them.  It would be useful for people to explore
various ways.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

> It is not immediately obvious what interface is best
> to help various users with various situations ask
> for what is best for them.  It would be useful for
> people to explore various ways.

Agreed.  Please do explore.

As I said earlier:

  > Just an idea.  Not sure if it's worth implementing,
  > but I think it would be useful.

  Good.  All ideas are helpful.

And still earlier:

  > I have two ideas for changes:
  > * Ask whether to include this part.
  > * Inform people that they could delete it if
  >   they don't want it posted to the bug tracker.

  Or offer the choice [between those] - via an option.

So yes, let's explore various ways to help users
provide what they want to provide and to be aware
of what they're sending.

You also said:

  > I think the simplest possible way is to identify
  > the data that might be sensitive, and help users
  > exclude all that data.

I don't disagree with that.  How best to help them
exclude "that data", i.e., any data they might feel
then don't want to send?

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Pankaj Jangid]

Drew Adams <drew.adams@oracle.com> writes:
> Let users decide.  A simple option takes care of this.  ...  I see no
> reason why we wouldn't want to let users decide, in this regard -
> whether it's about privacy or any other reason a user might have for
> her preference.

It is not that simple. Many big corporates are fighting suites for
this. FB, Google all take users' consent and then they do all sorts of
things that the users didn't think they would do.

"Users' intelligence is very overrated", my opinion.

> What's the difficulty or downside to doing this?

Another, thing is that the current setup makes is really simple for an
expert user to report bugs. I just run "emacs -Q" and try to reproduce
the issue and if it exists, I just shoot the mail with just the steps to
reproduce without worrying about which commit, which packages installed,
etc.

Regards,
-- 
Pankaj Jangid

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

> > Let users decide.  A simple option takes care of this.
> > ...  I see no reason why we wouldn't want to let users
> > decide, in this regard - whether it's about privacy or
> > any other reason a user might have for her preference.
> 
> It is not that simple. Many big corporates are fighting suites for
> this. FB, Google all take users' consent and then they do all sorts of
> things that the users didn't think they would do.
> 
> "Users' intelligence is very overrated", my opinion.

That doesn't counter the position that users should
be allowed to decide.

That may be an argument for making the default behavior
to be to exclude all, instead of to include all, of the
info that we currently collection in a hard-coded way.

The point is not that Emacs should automatically
collect such info.  The point is to give users an easy
way express their preference.

You are apparently making an argument that users
shouldn't have to do anything to opt out of sending
info.  They should instead need to opt in to sending
any such.  I have no problem with that.

What we do now is include everything by default, and
if a user doesn't want to include some of that then
she needs to explicitly, manually, delete it from
what gets sent.  And she needs to do that each time
she sends a bug report.

The point of my suggestion is to make it easy for a
user to define her own default behavior.  If the
default for that user option should be to send no
information then I'm OK with that too.

> > What's the difficulty or downside to doing this?
> 
> Another, thing is that the current setup makes is really simple for an
> expert user to report bugs. I just run "emacs -Q" and try to reproduce
> the issue and if it exists, I just shoot the mail with just the steps
> to reproduce without worrying about which commit, which packages
> installed,
> etc.

I thought you were making an argument for not just
including all such info.  Now it sounds like you're
arguing the opposite.  I don't see the relation
between the two.  And I don't see what any of what's
been discussed has to do with worrying about which
packages are installed etc.

In any case, any user, including any expert user,
can easily have the same behavior as she has now.
And in the patch I provided that would even be the
default behavior, so the expert user would not need
to change anything.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I agree.  We should not automatically include potentially sensitive
> user data in bug reports.  We can ask for it in the (presumably rare)
> cases when we do need to see those messages.
>
> How about the attached patch?

Looks good to me.

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

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

>   > 1. There's an option that lets you choose which
>   >    fields to include by default, when reporting
>   >    a bug: `ebp-report-emacs-bug-included-fields'.
> 
> This would be extra complication, the opposite of what we want in
> general.

Why?  What we have now is no possibility to express
your preference of what to include (by default).

With the option, if a user does nothing, she gets
just what she gets now: everything included.  Easy.

All the option does is let you, a user, decide what
to include by default, should you want to do that.

What's the complication?  Certainly there's nothing
complicated for a user.  Who's life is complicated
by giving users such a choice?

> The specific problem here is that report-emacs-bug includes data that
> might be sensitive.

The specific problem is that it includes data that
some users might not want to send - for whatever
reason.

And it does so systematically.  The only recourse
for a user is to manually delete whatever info she
doesn't want to send - each time, for each bug
report.  How is that helpful to users?

> It would be good to remind people that they don't
> have to send that data,

And to tell them what all that data is - the various
fields/sources.

And to show them where it is (especially because the
buffer does not make very clear which text gets sent
and which does not (boilerplate instructions/help).
Identify the data - point it out.

> and help them avoid it if/when they want to.

There's currently no way to "avoid" inclusion of
any of the text.  Users can only delete it manually
before sending the message.

Avoiding would prevent inclusion in the first place.
All we have is after-the-fact, on-demand deletion.

> But let's do that in the simplest possible way.

The simplest way is to not make the user do anything,
to send everything - like now.

But to also let a user state her general preference.
Let her decide what the default behavior is.  Not
that every user has to do that, or will want to do
that, but that any user can.

Alternatives that just point out the fields, or even
provide easy ways to delete them, still make users
to do that manually.  And each time, for each report.

How is that simpler and safer for users?

> I think the simplest possible way is to identify the data that might
> be sensitive, and help users exclude all that data.

The best way to help users exclude any data they
might want to exclude, by default, is to provide an
option that lets them do just that: set their own
preferred behavior.

What's complicated is making a complicated issue
out of this.  There's a simple solution that has no
effect on any user who doesn't care, and that lets
any user who does care get exactly the behavior she
wants, by default, and that lets her override her
own default for any given report.

defaults contents of report-emacs-bug

[Glenn Morris]

Richard Stallman wrote:

>   > > Except it has "Recent input:" section 2 pages down the report
>   > > that may contain sensitive data?
>
> On some occasions, it might do harm.

This item was removed 5 years ago, in Emacs 24.5.

https://debbugs.gnu.org/18900

Re: defaults contents of report-emacs-bug

[Sergey Organov]

Glenn Morris <rgm@gnu.org> writes:

> Richard Stallman wrote:
>
>>   > > Except it has "Recent input:" section 2 pages down the report
>>   > > that may contain sensitive data?
>>
>> On some occasions, it might do harm.
>
> This item was removed 5 years ago, in Emacs 24.5.
>
> https://debbugs.gnu.org/18900

Good. I use GNU Emacs 24.4.1 that explains why I see the item.

This fact also demonstrates that for many Emacs users only those
improvements (to the ways of reporting bugs) that are external to Emacs
will have prompt effect.

-- Sergey

Re: defaults contents of report-emacs-bug

[Sergey Organov]

Glenn Morris <rgm@gnu.org> writes:

> Richard Stallman wrote:
>
>>   > > Except it has "Recent input:" section 2 pages down the report
>>   > > that may contain sensitive data?
>>
>> On some occasions, it might do harm.
>
> This item was removed 5 years ago, in Emacs 24.5.
>
> https://debbugs.gnu.org/18900

Good. I use GNU Emacs 24.4.1 that explains why I see the item.

This fact also demonstrates that for many Emacs users only those
improvements (to the ways of reporting bugs) that are external to Emacs
will have prompt effect.

-- Sergey

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  >   You should report it with M-x report-emacs-bug".  But they don't,
  > and my impression is that it seems scary.  The report seems to go into
  > an official secret place or something?

Would you like to have discussions with a few of those people, to figure
out what specific aspects make it scary?  We need to really understand this
in order to find the least painful solution.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 22.11.2019 5:38, Richard Stallman wrote:
> [[[ 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. ]]]
> 
>    > The larger audience I meant here are the existing users of Emacs. A lot
>    > of which avoid reporting bugs to Debbugs. And I know that because I
>    > maintain some third-party packages with different issue trackers.
> 
> Maybe some of the people who report bugs for other packages might
> avoid reporting bugs for Emacs.  If so, could you ask them why they
> avoid it?

I've been repeating "use M-x report-emacs-bug" in various comments 
everywhere like a mantra, but even out of people who say they will file 
a report, less than half do so (judging by the reports which do appear 
in the tracker. Here's the latest occurrence: 
https://github.com/mooz/js2-mode/issues/539

As for why it happens, the possible reasons have been described multiple 
times:

- The interface is unfamiliar, the user doesn't understand what's going 
to happen,
- Their Emacs is likely not to have SMTP configured, and the necessity 
to copy over the report's contents to their email client is not clear 
for most,
- Even if they do manage the above step, the bug tracker is like a black 
hole: you get a notification that a bug was filed, and that's it. In all 
likelihood nobody is going to respond for the new few days (or months). 
And if they do, it will be an unusual experience for many, having a bug 
discussion over email, with its own etiquette and everything. With no 
understanding who the participating people are.

Whereas in most other projects both the repository and the bug tracker 
the public and visible, and easy to observe that development work is 
going on, recent reports are being handled, meaning they are welcome, 
and whatever grievances the user has have the possibility to be fixed.

> The recommended way to report one does not involve using Debbugs directly.
> It is M-x report-emacs-bug.
> 
> Do they not know about report-emacs-bug?

Even those who know, often don't follow this process through to the end. 
I don't have the time to chase everybody with questions. I did that a 
few times (for those non-reporters) and got exactly zero follow-up 
responses.

Also: I think Yamamoto Mitsuharu's Mac Port changes the bug reporting 
address to his own mailbox: 
https://bitbucket.org/mituharu/emacs-mac/src/3bf213d502a8260d29f7f55eb0938fc0a2594ea2/lisp/mail/emacsbug.el#lines-140:142

And I'm not sure if I've ever seen him forward any reports to us. So the 
users of Mac port can't send us bug reports the usual way.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I've been repeating "use M-x report-emacs-bug" in various comments
> everywhere like a mantra, but even out of people who say they will
> file a report, less than half do so (judging by the reports which do
> appear in the tracker.

There's also another reason. If I have reported an issue to the
package's bug tracker, I might not feel responsible to report it, again.

> - Even if they do manage the above step, the bug tracker is like a
>   black hole: you get a notification that a bug was filed, and that's
>  it. In all likelihood nobody is going to respond for the new few days
> (or months). And if they do, it will be an unusual experience for
> many, having a bug discussion over email, with its own etiquette and
> everything. With no understanding who the participating people are.

That's not a bugtracker fault. We are simply too few people to handle
all bugs in time. Do you believe, using Gilab's issues would change
this? More responsiveness?

> Also: I think Yamamoto Mitsuharu's Mac Port changes the bug reporting
> address to his own mailbox:
> https://bitbucket.org/mituharu/emacs-mac/src/3bf213d502a8260d29f7f55eb0938fc0a2594ea2/lisp/mail/emacsbug.el#lines-140:142
>
> And I'm not sure if I've ever seen him forward any reports to us. So
> the users of Mac port can't send us bug reports the usual way.

This is not related to our discussion.

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 23.11.2019 10:36, Michael Albinus wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> I've been repeating "use M-x report-emacs-bug" in various comments
>> everywhere like a mantra, but even out of people who say they will
>> file a report, less than half do so (judging by the reports which do
>> appear in the tracker.
> 
> There's also another reason. If I have reported an issue to the
> package's bug tracker, I might not feel responsible to report it, again.

True, but I see the same pattern when giving this advice on 
StackOverflow and Reddit.

>> - Even if they do manage the above step, the bug tracker is like a
>>    black hole: you get a notification that a bug was filed, and that's
>>   it. In all likelihood nobody is going to respond for the new few days
>> (or months). And if they do, it will be an unusual experience for
>> many, having a bug discussion over email, with its own etiquette and
>> everything. With no understanding who the participating people are.
> 
> That's not a bugtracker fault. We are simply too few people to handle
> all bugs in time. Do you believe, using Gilab's issues would change
> this? More responsiveness?

No exactly. But you can trivially look at the other recently reported 
bugs, as well as the most recent discussions, and see that the project 
is lively. Like I already said in the paragraph you cut out.

>> Also: I think Yamamoto Mitsuharu's Mac Port changes the bug reporting
>> address to his own mailbox:
>> https://bitbucket.org/mituharu/emacs-mac/src/3bf213d502a8260d29f7f55eb0938fc0a2594ea2/lisp/mail/emacsbug.el#lines-140:142
>>
>> And I'm not sure if I've ever seen him forward any reports to us. So
>> the users of Mac port can't send us bug reports the usual way.
> 
> This is not related to our discussion.

Isn't it? Mac Port reuses our branding, but removes the main way of 
sending bug reports to us.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[VanL]

>>> Also: I think Yamamoto Mitsuharu's Mac Port changes the bug reporting
>>> address to his own mailbox:
>>> https://bitbucket.org/mituharu/emacs-mac/src/3bf213d502a8260d29f7f55eb0938fc0a2594ea2/lisp/mail/emacsbug.el#lines-140:142
>>
>> This is not related to our discussion.
>
> Isn't it? Mac Port reuses our branding, but removes the main way of sending bug reports to us.

In my experience following the EmacMac app's
documentation I knew to direct the bug report
to gnu-emacs and not to YM unless the trouble
was identifiably specific to EmacMac.app only.

-- 
© 2019 VanL
gpg using EEF2 37E9 3840 0D5D 9183  251E 9830 384E 9683 B835
          'If the bug bites,don't fight it.' -Nancy S. Steinhardt

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> No exactly. But you can trivially look at the other recently reported
> bugs, as well as the most recent discussions, and see that the project
> is lively. Like I already said in the paragraph you cut out.

You can subscribe to <bug-gnu-emacs@gnu.org>. You can use the debbugs
ELPA package. Granted, there's room for improvement, but we have them.

You could argue that the web-based issue trackers are more fancy. But
this is the problem: they are web-based. I'm using Emacs, and I want to
tackle my problems with Emacs. So whatever we end up, that is a
requirement I have. I don't say we shall use debbugs forever, but if we
move to another system, I don't want to loose this feature.

>>> Also: I think Yamamoto Mitsuharu's Mac Port changes the bug reporting
>>> address to his own mailbox:
>>> https://bitbucket.org/mituharu/emacs-mac/src/3bf213d502a8260d29f7f55eb0938fc0a2594ea2/lisp/mail/emacsbug.el#lines-140:142
>>>
>>> And I'm not sure if I've ever seen him forward any reports to us. So
>>> the users of Mac port can't send us bug reports the usual way.
>> This is not related to our discussion.
>
> Isn't it? Mac Port reuses our branding, but removes the main way of
> sending bug reports to us.

There might be a problem with this, don't know. But we're discussing
which BTS to use for Emacs. We're not discussing here, that everybody
who provides an Emacs package or an Emacs fork shall use the default
Emacs BTS.

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sat, 23 Nov 2019 17:04:42 +0100
> Cc: ofv@wanadoo.es, larsi@gnus.org, perry@piermont.com, rms@gnu.org,
>  emacs-devel@gnu.org
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > No exactly. But you can trivially look at the other recently reported
> > bugs, as well as the most recent discussions, and see that the project
> > is lively. Like I already said in the paragraph you cut out.
> 
> You can subscribe to <bug-gnu-emacs@gnu.org>. You can use the debbugs
> ELPA package. Granted, there's room for improvement, but we have them.

Just to remind us, again: debbugs does have a Web based UI that allows
to look at recently reported bugs and their discussions.  It only
doesn't allow making any changes, not even reporting a new bug or
closing an existing one.  (It does allow to download a bug's
discussion or any one of the messages posted in that discussion, as an
mbox file, which one can then point one's MUA at and read/respond.
Assuming one's MUA supports importing mbox files, that is; Emacs's
MUAs do.)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 23.11.2019 18:04, Michael Albinus wrote:
> You can subscribe to<bug-gnu-emacs@gnu.org>. You can use the debbugs
> ELPA package. Granted, there's room for improvement, but we have them.

I'm not asking for myself. The question was why a lot of users shy away 
from reporting bugs to us.

> You could argue that the web-based issue trackers are more fancy. But
> this is the problem: they are web-based.

It's not that they are more fancy (though they are), they are more 
familiar to a lot of people. So they lower the barrier for 
participation, in a lot of ways.

 > I'm using Emacs, and I want to
tackle my problems with Emacs. So whatever we end up, that is a
requirement I have. I don't say we shall use debbugs forever, but if we
move to another system, I don't want to loose this feature.

I'm pretty sure we have discussed this requirement at length.

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

> The question was why a lot of users shy away
> from reporting bugs to us.

That's an assumption at this point, no?  What
evidence has been presented, besides anecdotal?

You said that you ask people right and left to
file bug reports, but many don't do so.  You
can legitimately ask why, I guess, if that's
true.

But I noted the opposite, in my experience.
I do the same thing, on the same sites you
mentioned, and IME most _do_ follow up by
filing bugs.  I consider it a good way to
inform users about `M-x report-emacs-bug'
and to encourage them to get involved by
suggesting enhancements and pointing out
problems they encounter.

Granted, I think posters on Reddit are maybe
less likely than those on emacs.StackExchange
or StackOverflow.  I've had good luck with
those Q&A sites.

But my point is that your reports and my
reports about this are anecdotal.  Why do we
think that lots of people, as you say, are
really scared away by `M-x report-emacs-bug'?
Is that a fact?  If so, how do we know that?

I see hand-waving about what users are used
to and assumptions that they won't use email
to report bugs.

It might be true that younger people use email
less than older people.  But are we sure this
has _in fact_ been a problem holding younger
users back from reporting bugs and suggesting
enhancements?

People use all kinds of ways to communicate
now - not just email, of course, but not just
GIT either.  And Emacs users need not be
developers.

So far, this sounds a bit like a solution in
search of a problem.  Where's the evidence
that email reporting is holding users back?

---

On another front, I will say this, not about
a web tracker but about our web page for Emacs
bugs, debbugs.gnu.org/: I think it could use
some improvement.

It's OK, if you know a bug number or you just
want to see the latest 10 bugs or so.

I do use that web page/interface, when I want
to see all of a thread I'm interested in.

More commonly, I use it when I want to point
someone (e.g. at one of the Q&A/discussion
sites we've mentioned) to a particular bug
thread - just give 'em a URL.

But to be frank, I've never been able to _find_
bugs on that site by searching.  I find it
incomprehensible and unhelpful.  Maybe that's
just me; dunno.

Instead, if I need to search for a bug I search
emails I've saved locally in my mail client.
Seriously.  After I've found the bug I might go
to debbugs.gnu.org to see the complete thread
or to get a URL for a thread or message.

Note that this is _very_ different from the use
of GNU mailing-list archives, such as
lists.gnu.org/archive/html/emacs-devel/.

Not that search is better there (it's not). But
for finding things in other ways (date, Subject),
and for accessing a thread tree or parts of it,
I find it superior to debbugs.gnu.org.  I can
understand it, and I can find what I need there.

Yes, I know that the purposes are very different:
mailing list archive vs bug interface.  Even so,
I think adding to debbugs.gnu.org the kind of
email-archive access/organization we have for the
mailing lists would already provide an improvement.

It's not very important to me whether what I'm
saying has an effect on this discussion.  I'm not
proposing anything - just relating my use and
impression of debbugs.gnu.org as a web interface.

One takeaway, though, from this post: Regardless
of any other value of having a web interface
(whether or not people can use it to file or
modify bugs, i.e., even if its only use is to view
them), there is value in being able to point users
to a bug thread on the web.  AFAIK, that value
hasn't yet been pointed out here.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Perry E. Metzger]

On Sat, 23 Nov 2019 17:57:25 -0800 (PST) Drew Adams
<drew.adams@oracle.com> wrote:
> > The question was why a lot of users shy away
> > from reporting bugs to us.  
> 
> That's an assumption at this point, no?  What
> evidence has been presented, besides anecdotal?

Only anecdotal evidence is possible, so I don't see that as avoidable.

I will say this: my anecdotal evidence matches that of others here.
In theory, the current bug reporting system is fine. In practice, it
conflicts with the way modern users are used to doing things and with
the configuration of modern single user systems.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Perry E. Metzger wrote:

> Only anecdotal evidence is possible, so
> I don't see that as avoidable.
>
> I will say this: my anecdotal evidence
> matches that of others here. In theory, the
> current bug reporting system is fine.
> In practice, it conflicts with the way modern
> users are used to doing things and with the
> configuration of modern single user systems.

OK, obviously we should keep the
`report-emacs-bug' stuff, it is fun and fast
once you get the hang of it.

However why don't you just set up a parallel
system, another interface, more modern in the
sense that has been mentioned, but something
that ultimately will do the same thing? Have it
all interconnected?

So everyone can use whatever interface they
like, much like some people use
gmane.emacs.help, others help-gnu-emacs with
mail splitting, and so on?

More roads -> more traffic!

What's the hesitation?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > However why don't you just set up a parallel
  > system, another interface,

Another _interface_ is one thing.  A _parallel system_ is another.

There can't be any harm in offering another interface to the same
bug data base.  Some people will prefer it; those who prefer the current
email interface will keep using it.

However, another bug tracking system in parallel with Debbugs would
cause big trouble.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Richard Stallman wrote:

>> However why don't you just set up a parallel
>> system, another interface,
>
> Another _interface_ is one thing. A _parallel
> system_ is another.

It can be, but here it isn't, as I'm sure you
understood the first time...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > > Another _interface_ is one thing. A _parallel
  > > system_ is another.

  > It can be, but here it isn't, as I'm sure you
  > understood the first time...

No, I don't understand.

Duplicating data in two databases generally creates the risk that they
get out of sync.  That is the disadvantage.


-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Richard Stallman wrote:

>>> Another _interface_ is one thing.
>>> A _parallel system_ is another.
>
>> It can be, but here it isn't, as I'm sure
>> you understood the first time...
>
> No, I don't understand.
>
> Duplicating data in two databases generally
> creates the risk that they get out of sync.
> That is the disadvantage.

        old                  new
     e-mail <-> database <-> web
interface_1                  interface_2

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

> > > The question was why a lot of users shy away
> > > from reporting bugs to us.
> >
> > That's an assumption at this point, no?  What
> > evidence has been presented, besides anecdotal?
> 
> Only anecdotal evidence is possible, so I don't
> see that as avoidable.

Other ways to gather evidence are possible.

But even if anecdotal evidence were all that was
possible, it remains not super useful for making
decisions about which bug reporting, tracking,
and management tools to use.

That's all the more important if the choice is to
abandon the current system altogether and switch
to another one, instead of letting users continue
to use email, as well letting them use other ways
to report bugs and enhancement requests. 

> I will say this: my anecdotal evidence matches
> that of others here.

Which others?  What's your anecdotal evidence about
whether users report bugs if you suggest to them to
use `M-x report-emacs-bug'?

> In theory, the current bug reporting system is fine.
> In practice, it conflicts with the way modern users
> are used to doing things and with the configuration
> of modern single user systems.

That's not what I, and the post I responded to, was
referring to.  That's a much more general question.

I was speaking to the narrower question of whether
they report a bug, when we suggest to users (of
Emacs Q&A or discussion web sites) that, for their
particular observation, suggestion, or question,
they use `M-x report-emacs-bug'.

My anecdotal finding is that they do.  The anecdotal
finding I responded to was that they don't - because
they're scared of sending an email.

I've said that anecdotal evidence isn't super useful.
But it can be of some use - different observations
can help.

But at least we shouldn't jump from one person's
observation to a general presumption that "a lot
of users shy away from reporting bugs to us".

I offered my contrary observation.  And I thought
it was worthwhile to point out that we were both
offering just personal anecdotes.

Why is the narrower question useful?  It can speak,
even if only anecdotally, to the extent to which
users don't report bugs because they need to send
email (whether from fear or any other reason).

The claim for which I said evidence hasn't been
presented was that "a lot of users shy away from
reporting bugs to us".  That claim then tried to
direct discussion to why that presumed fact is so.

I asked how we know it to be a fact.  Shades of the
classic, "When did you stop beating your wife?"
The question why lots of users are afraid to report
bugs begs the question of whether they in fact are.

The claim you make is that `M-x report-emacs-bug'
"conflicts with" what "modern users" are used to,
and with the computer systems they use (no email?).

If such users don't hesitate to `report-emacs-bug',
then where's the conflict?  (I assume users on the
sites I mentioned include some of your "modern users".)

Whether there might be other useful ways to let
users report bugs is a different question.  That
possibility could be offered instead of, or in
addition to, `M-x report-emacs-bug' (email).  

I gather, from your claim of "conflict" that you
favor the former.  A priori, I'd prefer the latter:
let users optionally continue to use email to
report, if they like.

But whether such other ways (from Slack-like to
GitHub-like, to JIRA-like, to any number of other
"way[s] modern users are used to doing things")
might be _useful_ is quite a different question
from whether such ways "conflict with the current
bug reporting system".

Please don't confuse such different questions in
your zeal to promote a particular recourse.

These are (should be, anyway) still early days
wrt finding out what the actual story is and
then, if need be, examining possible remedial
actions.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Drew Adams wrote:

>> Only anecdotal evidence is possible, so
>> I don't see that as avoidable.
>
> Other ways to gather evidence are possible.
>
> But even if anecdotal evidence were all that
> was possible, it remains not super useful for
> making decisions about which bug reporting,
> tracking, and management tools to use.

Well, no smoke without fire. And again, more
roads, more traffic.

So I think it just comes down to if anyone is
willing to set up a new system that works
transparently and in parallel with the
previous.

If anyone is there should be no hesitation.

Do it today, in a different way!

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> Date: Sat, 23 Nov 2019 17:57:25 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: ofv@wanadoo.es, larsi@gnus.org, emacs-devel@gnu.org, rms@gnu.org,
>  perry@piermont.com
> 
> But to be frank, I've never been able to _find_
> bugs on that site by searching.  I find it
> incomprehensible and unhelpful.  Maybe that's
> just me; dunno.

Just you, IMO.  I use the search capability there a lot, and I'm very
pleased with how it finds bugs.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

> But to be frank, I've never been able to _find_
> bugs on that site by searching.  I find it
> incomprehensible and unhelpful.  Maybe that's
> just me; dunno.

Maybe you're hit by the fact, that debbugs does not search for free
text, but words. So you cannot search for "current-buffer", because it
is not a word due to the hyphen. OTOH, a search for "current AND buffer"
should return myriad of hits.

(Both untested, debbugs.gnu.org is not reachable just now.)

Best regards, Michael.

RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams]

> > But to be frank, I've never been able to _find_
> > bugs on that site by searching.  I find it
> > incomprehensible and unhelpful.  Maybe that's
> > just me; dunno.
> 
> Maybe you're hit by the fact, that debbugs does
> not search for free text, but words.

Maybe.  I tried various things many years ago,
but never succeeded at making good use of it.
I gave up trying, admittedly.

FWIW, I have no trouble with search elsewhere,
whether so-called "advanced" search (Booleans,
dates etc.) or more run-of-the-mill search.

> So you cannot search for "current-buffer",
> because it is not a word due to the hyphen.
> OTOH, a search for "current AND buffer" should
> return myriad of hits.

I'm pretty sure that wasn't among the problems
I had with it.  I'm used to typical "full-text"
search, which is indexed and often word-based.

Anyway, my mention of this wasn't to convince
anyone.  If no one else has a problem with it,
that's good news.

> (Both untested, debbugs.gnu.org is not
> reachable just now.)
> 
> Best regards, Michael.

Ditto.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Philippe Vaucher]

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

>
> > You could argue that the web-based issue trackers are more fancy. But
> > this is the problem: they are web-based.
>
> It's not that they are more fancy (though they are), they are more
> familiar to a lot of people. So they lower the barrier for
> participation, in a lot of ways.


Also because you can contribute/report a bug while you are in your browser
just looking at an API makes it very tempting to do so.

For example I have fixed lots of typos in various projects just because the
"Edit in a fork" button was there while I browsed the code curiously. I
would never even have looked at the code if I had to clone it first, let
alone create a patch if it requires me to register to a mailing list.

Also, there's always https://github.com/nlamirault/emacs-gitlab, but at the
moment it looks like it has issues.

Kind regards,
Philippe

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Per Starbäck]

Michael Albinus wrote:
> You could argue that the web-based issue trackers are more fancy. But
> this is the problem: they are web-based. I'm using Emacs, and I want to
> tackle my problems with Emacs.

I think report-emacs-bug should be done with Emacs *and* be web-based.

My vision is that Emacs should talk to the bug database over the net
by contacting it via http(s).There should be an interface that could
show a buffer with information about a specific bug. (That page would
among other things mention the url where you can see the same
information in a general web browser.) There should be a command in
Emacs to search the bug database. The result of such a search can be
compared for example to the *Packages* buffer when doing M-x
package-list-packages. It lists resources that are available on the
net. By clicking on them you get more information about them. You can
mark bugs you are interested in and they are highlighted. Which bugs
you are interested in are stored in some file in .config/emacs/ and
when you last visited them, so you can get special highlight if it has
been updated since you last visisted it.

With report-emacs-bug you start writing a bug report for entering in
the database. When you end it (with C-c C-c) you may get to see a list
of possibly related bugs first and asked if it's a duplicate of any of
those. After you've entered it you see it highlighted in a list of
bugs, so you can immediately see what your report actually resulted
in. Of course the bug you reported will be marked. I think the list to
show should after reporting a bug should be the list of bugs you
marked ordered by when they were last changed, so the bug you just
reported would come first.

There should be a main Emacs bug buffer from where you can search,
bring up predefined lists, like "marked bugs", "latest reported bugs",
"latest updated bugs", and report a new bug.

-*-
These are a lot of wishes with no code. I think the general idea is
sound, though. Reporting, viewing and searching are all important
activities with bugs. It's unfortunate if we only have a way to do one
of those three directly from Emacs and that they are not tied
together. And I think that it's not necessary to see mail as the most
natural way for Emacs to communicate with the outside anymore.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Per Starbuck wrote:

>> You could argue that the web-based issue
>> trackers are more fancy. But this is the
>> problem: they are web-based. I'm using
>> Emacs, and I want to tackle my problems
>> with Emacs.
>
> I think report-emacs-bug should be done with
> Emacs *and* be web-based.

I know right?

> -*- These are a lot of wishes with no code.
> [...]

Are you sure? Grep the [M]ELPAs for a lot of
hits on "bug" - a lot is bug as in debugger,
but some is bug as in bug tracker, e.g.

debbugs   0.19   available   gnu elpa   SOAP library to access debbugs servers

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Per Starbäck <per@starback.se> writes:

> These are a lot of wishes with no code. I think the general idea is
> sound, though. Reporting, viewing and searching are all important
> activities with bugs. It's unfortunate if we only have a way to do one
> of those three directly from Emacs and that they are not tied
> together. And I think that it's not necessary to see mail as the most
> natural way for Emacs to communicate with the outside anymore.

Some of the wishes are already implemented by the debbugs ELPA
package. You are invited to request enhacements for that.

(And I also keep your wishes in mind when I touch the package next
time.)

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > I think report-emacs-bug should be done with Emacs *and* be web-based.

This would exclude people who are editing without an internet connection,
as I often am.

Offering the option of web-based transmission is fine, and may be
a big improvement.  But don't eliminate the existing method of
sending email.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> That's not a bugtracker fault. We are simply too few people to handle
> all bugs in time. Do you believe, using Gilab's issues would change
> this? More responsiveness?

I think that's likely -- just because other people (not intimately
involved with Emacs development) are apt to chime in with suggestions,
testing and solutions.

That's one of the major points of moving to bug reporting process that's
more familiar to most people these days: To get more people to
participate.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > Whereas in most other projects both the repository and the bug tracker 
  > the public and visible, and easy to observe that development work is 
  > going on, recent reports are being handled, meaning they are welcome, 
  > and whatever grievances the user has have the possibility to be fixed.

This is an argument that users often would _like_ to look at the bug
tracker.  They don't _need_ it, but having it would motivate them.

This suggests that we do want a web interface to the bug tracker.
But we don't have to replace the bug tracker.  A web interface to it
would do the job.

How hard is it to add that on top of Debbugs?

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Karl Fogel]

On 24 Nov 2019, Richard Stallman wrote:
>  > Whereas in most other projects both the repository and the bug tracker 
>  > the public and visible, and easy to observe that development work is 
>  > going on, recent reports are being handled, meaning they are welcome, 
>  > and whatever grievances the user has have the possibility to be fixed.
>
>This is an argument that users often would _like_ to look at the bug
>tracker.  They don't _need_ it, but having it would motivate them.
>
>This suggests that we do want a web interface to the bug tracker.
>But we don't have to replace the bug tracker.  A web interface to it
>would do the job.
>
>How hard is it to add that on top of Debbugs?

I mentioned this earlier in the thread, but it might be useful to do so again as a reply to your question above:

There was apparently a project to do this, some years ago:

  https://wiki.debian.org/SummerOfCode2007/DebbugsWebUI

At that time, Stefano Zacchiroli offered to help.  It was discussed on the Debian Devel mailing list, starting here:

  https://lists.debian.org/debian-devel/2007/03/msg00362.html
  To: Debian Devel ML
  Subject: co-mentor for a GSoC proposal wanted: debbugs web submission
  From: Stefano Zacchiroli
  Date: Thu, 15 Mar 2007 19:28:11 +0100
  Message-id: <20070315182811.GA19407@takhisis.invalid>

And it looks like some progress was made.  According to...

  https://wiki.debian.org/SummerOfCode2008/DebbugsWebUI
  https://wiki.debian.org/SummerOfCode2009/DebbugsWebUI

...the code had been at this now-obsolete URL:

  http://alioth.debian.org/projects/bts-webui/

However, I am unable to find that code on salsa.debian.org (the GitLab-based replacement for alioth) now.  I tried these searches:

  https://salsa.debian.org/search?search=bts-webui
  https://salsa.debian.org/search?search=bts
  https://salsa.debian.org/search?search=webui
  https://salsa.debian.org/search?search=debbugs

Does anyone know what happened with that project?  It might be a good starting point now.

Best regards,
-Karl

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Memnon Anon]

Richard Stallman <rms@gnu.org> writes:

>   > Whereas in most other projects both the repository and the bug tracker 
>   > the public and visible, and easy to observe that development work is 
>   > going on, recent reports are being handled, meaning they are welcome, 
>   > and whatever grievances the user has have the possibility to be fixed.
>
> This is an argument that users often would _like_ to look at the bug
> tracker.  They don't _need_ it, but having it would motivate them.

FWIW, I was always under the impression that, before you even consider
writing a bug report, it is good manners to check, whether the issue
is already reported, or perhaps solved in the dev branch.

Searching "proper bug reporting", the first thing I get is:

How to write a good bug report: step-by-step instructions

1.  Isolate bug. The first step in in writing a bug report is to
    identify exactly what the problem is. ...
2.  Check if you are using the latest version. Bug reports should be
    based on the the latest development build . ...
3.  Check if the bug is known. .
    ...

Memnon

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > FWIW, I was always under the impression that, before you even consider
  > writing a bug report, it is good manners to check, whether the issue
  > is already reported, or perhaps solved in the dev branch.

I just checked the section Reporting Bugs of the Emacs Manual and was
surprised to see that it asks users to look in debbugs.

That requires substantial work, and substantial knowledge that users
otherwise would not need to have, so it is a substantial
discouragement to reporting bugs.

It also asks users to look at several mailing lists.  That too is a
discouragement.

If we want to encourage users to report bugs, the obvious way is to
delete those recommendations.  Let's tell users, "It's better to risk
a duplicate bug report than risk leaving a bug unreported."

It could make sense to have a separate, following section in which we
say, "If you report bugs often and you would like to be
super-conscientious about avoiding duplicates, you could check for
whether each bug has already been reported by looking at...
But it's better to risk
a duplicate bug report than risk leaving a bug unreported.

I suggest making it a separate section because otherwise people might
think, "If I don't do these things, and I don't have time to do them,
it is better if I not send anything."

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 02 Dec 2019 00:41:36 -0500
> Cc: emacs-devel@gnu.org
> 
> I just checked the section Reporting Bugs of the Emacs Manual and was
> surprised to see that it asks users to look in debbugs.
> 
> That requires substantial work, and substantial knowledge that users
> otherwise would not need to have, so it is a substantial
> discouragement to reporting bugs.
> 
> It also asks users to look at several mailing lists.  That too is a
> discouragement.
> 
> If we want to encourage users to report bugs, the obvious way is to
> delete those recommendations.  Let's tell users, "It's better to risk
> a duplicate bug report than risk leaving a bug unreported."

I disagree with what you say here, at least with the details of your
proposal.  There are ways of making that chapter in the manual better,
but just removing this section is IMO not a step in that direction.
Here's why I think so.

First, that section was written in response to a bug report, see

  https://lists.gnu.org/archive/html/bug-gnu-emacs/2010-06/msg00509.html

So at least the person who filed that bug did care about having this
information in the manual.

Next, every decent bug tracker has a feature whereby it shows related
bugs; some even do that before they let you file a new bug.  Debbugs
doesn't have such (semi-)automatic feature, but if we move to a more
sophisticated tracker, or enhance debbugs, we will have to
re-introduce a variant of that section anyway, so why remove it now?

Moreover, I cannot disagree more with the notion of "it's better to
risk a duplicate bug report than risk leaving a bug unreported."
Having to deal with duplicate bugs eats up precious time and resources
(realize the bug is a dupe, mark it so in the database, write an email
saying it's a dupe, etc.), of which we don't have enough.  Duplicate
bugs within hours or days of one another are a matter of routine here,
and any method of making these typical floods of similar reports
smaller is a net win for us.  I agree that we shouldn't ask users to
look too far back into the bug reports (so the reference to
emacs-pretest-bug should probably be removed nowadays), but a simple
search via the debbugs page, or a casual skimming thorough the last
week or two of messages on the bug list and emacs-devel, is a small
effort that is likely to bring significant gains, and I do want to
leave them there.  OTOH, the risk that an important bug will be left
unreported is nowadays very small, since a lot of people are tracking
the development branch, and several distros offer snapshot releases.
Thus, we don't need to be afraid of bugs going unreported anymore as
much as we did in the past.

Last, but certainly not least, that chapter is anyway quite long.  It
includes, in addition to "Known Problems", the following sections:

  . Bug Criteria -- when an issue is really a bug
  . Understanding Bug Reporting -- how to describe a bug
  . Checklist -- what information to include in a bug report and how
    to obtain that information

This is quite a lot of material to digest if you are serious about bug
reporting and really read all that stuff before filing a bug.  If we
think what's in the "Known Problems" section requires substantial
work, then the other sections require much more.  Do we remove all
that as well?  I hope not.

And finally, we have strong indications that almost no one reads this
stuff anyway.  We have people reporting duplicates, we have people
(even quite experienced ones) reporting problems without the minimal
information about their build/system, sometimes even without a clear
description of what they did to trigger the issue.  My interpretation
of this is that this chapter is more like a repository of good ideas
and techniques to point users at, not a must-do list of prerequisites
for reporting a bug; it certainly isn't treated as such by our users.
It is therefore not a substantial discouragement, let alone an
obstacle, to reporting bugs, not in practice.

So what does all that mean in terms of improving the UX of bug
reporting?  We could add a short checklist "for the impatient" right
at the beginning of the chapter, describing concisely the necessary
steps, and then encourage them to read the rest, saying that this will
make the bug report be more useful and help the Emacs developers
identify and resolve the issue much more efficiently.  But I would
definitely object to removing these sections, including "Known
Problems", from the chapter, as most of that is very useful, and if
followed, makes the bug reports much easier to deal with.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Jean-Christophe Helary]

> On Dec 3, 2019, at 0:42, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> So what does all that mean in terms of improving the UX of bug
> reporting?  We could add a short checklist "for the impatient" right
> at the beginning of the chapter,

Yes !!!


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Jean-Christophe Helary wrote:

>> So what does all that mean in terms of
>> improving the UX of bug reporting? We could
>> add a short checklist "for the impatient"
>> right at the beginning of the chapter,
>
> Yes !!!

Well, do that by all means but I think focus
should be on the *Bug Help* buffer and/or the
actual mail as that is the only thing the
really impatient will ever see.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Emanuel Berg via Emacs development discussions.]

Eli Zaretskii wrote:

> So what does all that mean in terms of
> improving the UX of bug reporting? We could
> add a short checklist "for the impatient"
> right at the beginning of the chapter [...]

I agree, don't remove any material that is
technically correct and written in a balanced
and objective tone.

I also agree re: composition, put the most
important material first, simplify to a bunch
of slogans if need be! but obviously don't
simplify beyond the line of, err, correctness.

After that, again assuming everything's sound,
please go on, elaborate everything 10 or 100
pages, or just how many it takes!

The journey is the goal...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 20 Nov 2019 22:06:46 -0500
> Cc: ofv@wanadoo.es, larsi@gnus.org, emacs-devel@gnu.org, michael.albinus@gmx.de,
>  perry@piermont.com
> 
> Sure, all else being equal we would prefer to offer more
> convenient interfaces.  But is that such an imperative
> that we would want to pay a price for it?  I am skeptical.

I think the idea is that most people nowadays have some kind of
account already -- either in gmail, or in facebook, or in one of the
other services that GitLab is capable of using instead of a GitLab
specific registration.  So for those people who have one of these
accounts, registration is not an issue, and there's no real price to
pay.

Importing past bugs is another matter: here we would like it to be
possible to have the person who originally reported an issue to be
included in the email notifications if someone posts comments to the
bug report.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

[Alan Mackenzie]

Hello, Eli.

On Thu, Nov 21, 2019 at 16:14:10 +0200, Eli Zaretskii wrote:
> > From: Richard Stallman <rms@gnu.org>
> > Date: Wed, 20 Nov 2019 22:06:46 -0500
> > Cc: ofv@wanadoo.es, larsi@gnus.org, emacs-devel@gnu.org, michael.albinus@gmx.de,
> >  perry@piermont.com

> > Sure, all else being equal we would prefer to offer more
> > convenient interfaces.  But is that such an imperative
> > that we would want to pay a price for it?  I am skeptical.

> I think the idea is that most people nowadays have some kind of
> account already -- either in gmail, or in facebook, or in one of the
> other services that GitLab is capable of using instead of a GitLab
> specific registration.

Please reconsider.  I don't think the GNU project should in any way
endorse companies like Facebook or Google or Microsoft, which are no
friends of free software (except their use of free (as in beer)
software).  Their way of making money is by immorally, surreptitiously,
and in many cases illegally collecting their users' personal data and
selling it on.

> So for those people who have one of these accounts, registration is
> not an issue, and there's no real price to pay.

There would be a heavy price for the GNU project, namely its
credibility.

Not even if it makes authentication easier for some users.  It is a line
we just shouldn't cross.

Personally, I think requiring any sort of registration to report a bug
is so inconsiderate that we just shouldn't do it.  Reporting a bug takes
a significant amount of effort as it is, and requiring people who do it
to register is like a slap on the face.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

[Eli Zaretskii]

> Date: Thu, 21 Nov 2019 17:59:27 +0000
> Cc: rms@gnu.org, ofv@wanadoo.es, perry@piermont.com, michael.albinus@gmx.de,
>   dgutov@yandex.ru, larsi@gnus.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I think the idea is that most people nowadays have some kind of
> > account already -- either in gmail, or in facebook, or in one of the
> > other services that GitLab is capable of using instead of a GitLab
> > specific registration.
> 
> Please reconsider.  I don't think the GNU project should in any way
> endorse companies like Facebook or Google or Microsoft, which are no
> friends of free software (except their use of free (as in beer)
> software).

We are not endorsing any of them when we ask our users to report bugs
and contribute code.  We welcome and gratefully accept any such bug
reports and code contributions, and don't request those who contribute
to pledge allegiance to the ideals of the GNU Project or free software
in general.  Exactly like becoming an official maintainer of a GNU
project does not require one to agree with the goals of GNU, it only
requires one to heed to the policies specified by the GNU Project.

E.g., my main development machine runs MS-Windows, but that doesn't
mean the GNU Project endorsed Microsoft when it appointed me, or that
I somehow "betray" GNU.

So I think you misunderstand the basic nature of the relationship
between the GNU Project and the developers of the projects' software.

> Personally, I think requiring any sort of registration to report a bug
> is so inconsiderate that we just shouldn't do it.

We don't require it.  I said that most people will not need to
register, that's all.  I do understand how this could be an obstacle
for those who don't already have an account, and would be much happier
if this obstacle didn't exist.  But saying that we somehow endorse
whatever services can be used instead of registering is IMO a far cry
from the reality of the GNU Project's relationship with its software
developers and contributors.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

[Perry E. Metzger]

On Thu, 21 Nov 2019 20:18:48 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> E.g., my main development machine runs MS-Windows, but that doesn't
> mean the GNU Project endorsed Microsoft when it appointed me, or
> that I somehow "betray" GNU.

I think this is precisely right, fwiw.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

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

  > We are not endorsing any of them when we ask our users to report bugs
  > and contribute code.  We welcome and gratefully accept any such bug
  > reports and code contributions, and don't request those who contribute
  > to pledge allegiance to the ideals of the GNU Project or free software
  > in general.  Exactly like becoming an official maintainer of a GNU
  > project does not require one to agree with the goals of GNU, it only
  > requires one to heed to the policies specified by the GNU Project.

This is entirely true.  However, this is a different issue
from the one that was raised by the following cited text:

> > I think the idea is that most people nowadays have some kind of
> > account already -- either in gmail, or in facebook, or in one of the
> > other services that GitLab is capable of using instead of a GitLab
> > specific registration.


-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

[Dmitry Gutov]

On 21.11.2019 19:59, Alan Mackenzie wrote:
>> So for those people who have one of these accounts, registration is
>> not an issue, and there's no real price to pay.
> There would be a heavy price for the GNU project, namely its
> credibility.

Other, bigger parts of GNU already do this. The GNOME Project, for example.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

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

  > Other, bigger parts of GNU already do this. The GNOME Project, for example.

That is a problem.  That one problem exists is no reason
to make another similar problem.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

[John Wiegley]

>>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

AM> Their way of making money is by immorally, surreptitiously, and in many
AM> cases illegally collecting their users' personal data and selling it on.

One thing the free software movement should strengthen is selling users on the
merits of its ideals, and not try to distinguish itself by painting the other
side in such a lopsidedly evil light.

I know many people who work at Apple; I know family who work at Apple. All of
my own hardware is from Apple. Yet they do not, as the above sentence might
suggest, gather together in dark rooms to render kitten fat over bubbling
cauldrons. If that sounds hyperbolic, it gives you some idea of how statements
like the above come across to someone who is sympathetic both to users (who of
course desire complete freedom) and corporations (who desire to stay in
business, and are beholden to more entities than just their users).

Could large companies do better? Of course they could. The Free Software
Foundation might even be the one to show them the path to a better way. But
vilifying the opposition does not make your case in the eyes of those who
don't already agree with you.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

[Alan Mackenzie]

Hello, John.

On Thu, Nov 21, 2019 at 14:32:50 -0700, John Wiegley wrote:
> >>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

> AM> Their way of making money is by immorally, surreptitiously, and in many
> AM> cases illegally collecting their users' personal data and selling it on.

> One thing the free software movement should strengthen is selling users on the
> merits of its ideals, and not try to distinguish itself by painting the other
> side in such a lopsidedly evil light.

You're suggesting that my sentence above is unfair and lopsided.  It was
intented to be accurate and fair, and I believe it is, as much as it can
be in a single short summary sentence.

> I know many people who work at Apple; I know family who work at Apple. All of
> my own hardware is from Apple. Yet they do not, as the above sentence might
> suggest, gather together in dark rooms to render kitten fat over bubbling
> cauldrons. If that sounds hyperbolic, it gives you some idea of how statements
> like the above come across to someone who is sympathetic both to users (who of
> course desire complete freedom) and corporations (who desire to stay in
> business, and are beholden to more entities than just their users).

I don't see what the above paragraph has to do with my sentence that you
quoted.  I purposely didn't include Apple in my "companies like that".
As you note, Apple has other flaws.  You seem to be denigrating what I
said by a straw man argument.

My point was that we should not encourage our users to submit to the
abuses of Google, Facebook et al. by facilitating the access to our
services to those who do so.  That would indeed be endorsement of them.

> Could large companies do better? Of course they could. The Free Software
> Foundation might even be the one to show them the path to a better way. But
> vilifying the opposition does not make your case in the eyes of those who
> don't already agree with you.

What I said is quoted above.  I believe it is literally true, fair, and
highly pertinent.  Sometimes, one must call a spade a spade, and draw a
line.  If I am mistaken, please say so and point out how, rather than
attacking me with straw man arguments.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

[John Wiegley]

>>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

AM> I don't see what the above paragraph has to do with my sentence that you
AM> quoted. I purposely didn't include Apple in my "companies like that". As
AM> you note, Apple has other flaws. You seem to be denigrating what I said by
AM> a straw man argument.

I misread you then, Alan, my apologies. I actively avoid using Google software
as well, because they install software without my consent that "phones home",
so perhaps I'm more aligned with your sentiments than I had realized.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

[Alan Mackenzie]

Hello, John.

Sorry for the delay in responding.  I've had a very busy weekend.

On Thu, Nov 21, 2019 at 21:30:55 -0700, John Wiegley wrote:
> >>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

> AM> I don't see what the above paragraph has to do with my sentence that you
> AM> quoted. I purposely didn't include Apple in my "companies like that". As
> AM> you note, Apple has other flaws. You seem to be denigrating what I said by
> AM> a straw man argument.

> I misread you then, Alan, my apologies.

No problem!

> I actively avoid using Google software as well, because they install
> software without my consent that "phones home", so perhaps I'm more
> aligned with your sentiments than I had realized.

Yes.  I don't use Google things either, and NoScript blocks out any of
their scripts used by third parties (of which there are a shocking
number).

"Phoning Home" from an EU state without the user's consent has been
unlawful for a year and a half now, at least.  It's a pity there has
been no firm enforcement procedings as yet.  Maybe they will come.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

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

  > My point was that we should not encourage our users to submit to the
  > abuses of Google, Facebook et al. by facilitating the access to our
  > services to those who do so.  That would indeed be endorsement of them.

You have said it very clearly.  Thank you.

If you (whoever you are) as a developer wish to do some of your
development work on MacOS, or do email through Gmail, we don't object.
For the former, we may not even notice.  That is your own personal
activity, and we don't make rules about that.

However, the issue here is whether the GNU Project should put certain
services on a list to be singled out for special positive treatment.
We will not do that with any service unless we consider it fully ethical.
Apple, Google and Facebook do not qualify.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

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

  > AM> Their way of making money is by immorally, surreptitiously, and in many
  > AM> cases illegally collecting their users' personal data and selling it on.

I don't know what fraction of Apple's income comes from surveillance,
but we know Apple does surveillance on its users.

  > not try to distinguish itself by painting the other
  > side in such a lopsidedly evil light.

We should not exaggerate Apple's evil, but we also know that Apple
does other nasty things to its users.  It is lopsidedly evil, with no
exaggeration required.  See https://gnu.org/malware/malware-apple.html.

  > Yet they do not, as the above sentence might
  > suggest, gather together in dark rooms to render kitten fat over bubbling
  > cauldrons.

I am sure they don't, but nobody here said they did.  Alan did not say
that.  You exaggerated his words to an extreme, which Alan is not
responsible for.  Sticking to facts, Apple is extremely nasty.
Recently Apple extended its system of censorship of apps to
Macintoshes.  As of a year ago, new Maxintoshes did not allow
installing GNU/Linux.

I am sure that plenty of people who work for Apple love their
families and their pets, but that does not lessen Apple's wrongs.



-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen.")

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

  > AM> Their way of making money is by immorally, surreptitiously, and in many
  > AM> cases illegally collecting their users' personal data and selling it on.

I don't know what fraction of Apple's income comes from surveillance,
but we know Apple does surveillance on its users.

  > not try to distinguish itself by painting the other
  > side in such a lopsidedly evil light.

We should not exaggerate Apple's evil, but we also know that Apple
does other nasty things to its users.  It is lopsidedly evil, with no
exaggeration required.  See https://gnu.org/malware/malware-apple.html.

  > Yet they do not, as the above sentence might
  > suggest, gather together in dark rooms to render kitten fat over bubbling
  > cauldrons.

I am sure they don't, but nobody here said they did.  Alan did not say
that.  You exaggerated his words to an extreme which Alan is not
responsible for.  Sticking to facts, Apple is extremely nasty.
Recently Apple extended its system of censorship of apps to
Macintoshes.  As of a year ago, new Maxintoshes did not allow
installing GNU/Linux.

I am sure that plenty of people who work for Apple love their families
and their pets, but that does not lessen or excuse Apple's wrongs.

  >  someone who is sympathetic both to users (who of
  > course desire complete freedom) and corporations (who desire to stay in
  > business, and are beholden to more entities than just their users).

Corporations are not people, and don't actually "desire" anything.
Unlike human beings, they don't intrinsically deserve to continue
to exist, and are not entitled to forgiveness for their wrongs
for their own sake.  They cannot excuse wrongdoing by pleading,
"We had to do this or fold."  If Apple folds, I will cheer.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Perry E. Metzger]

On Thu, 21 Nov 2019 16:14:10 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> Importing past bugs is another matter: here we would like it to be
> possible to have the person who originally reported an issue to be
> included in the email notifications if someone posts comments to the
> bug report.

One somewhat messy option would be to continue using debbugs for the
existing bug database, and to use Gitlab only for new bugs.
Presumably over time we would want to fix the bulk of what's
in the existing database anyway. When the number in the old database
gets small enough, one could find an ad hoc solution for the fairly
small number of bugs remaining.

I'm not completely sold on this idea myself, but it would be one way
to avoid making the transition simpler. It also has clear
disadvantages, including forcing the devs to deal with two bug
systems for quite a while.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[John Wiegley]

>>>>> "PEM" == Perry E Metzger <perry@piermont.com> writes:

PEM> One somewhat messy option would be to continue using debbugs for the
PEM> existing bug database, and to use Gitlab only for new bugs.

You never want to have to query two completely separate sources of work
requests.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > I think the idea is that most people nowadays have some kind of
  > account already -- either in gmail, or in facebook, or in one of the
  > other services that GitLab is capable of using instead of a GitLab
  > specific registration.

The GNU Project must never invite people to sign in to a GNU activity
using a Gmail or Facebook account.  To include those in a specific
list of a few options would be to give Gmail, or Facebook,
respectively, a special privileged position -- in effect promoting
Gmail or Facebook.  That would be wrong.

We will not _punish_ or _reject_ people just for using those
sites, but that is a different (though related) question.


-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ofv@wanadoo.es, perry@piermont.com, michael.albinus@gmx.de,
> 	dgutov@yandex.ru, larsi@gnus.org, emacs-devel@gnu.org
> Date: Thu, 21 Nov 2019 22:42:42 -0500
> 
>   > I think the idea is that most people nowadays have some kind of
>   > account already -- either in gmail, or in facebook, or in one of the
>   > other services that GitLab is capable of using instead of a GitLab
>   > specific registration.
> 
> The GNU Project must never invite people to sign in to a GNU activity
> using a Gmail or Facebook account.

We don't.  I'm just saying that many of them will, if we end up using
GitLab.  And I see no problem with that, exactly like we never ask
them which browser they use to send email to us or look at bug reports
on debbugs.

> We will not _punish_ or _reject_ people just for using those sites

That was my point, exactly.  Alan seemed to say that we should punish
them, or reject their submissions.

Anyway, this is all very theoretical at this point, since GitLab has
many other problems, which are of much more importance to us than this
one.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Achim Gratz]

Dmitry Gutov writes:
> On 20.11.2019 10:20, Michael Albinus wrote:
>> You need an account if you want to write a new bug report ("issue") in
>> Gitlab, even for public projects. No problem for Emacs developers, they
>> will have an account on Emacs' Gitlab stanza. But we will miss bug
>> reports from Emacs users, which usually have no account there.
>
> It has OAuth support, users could log in using an account from a
> number of popular services. So that should be a non-issue.

Which part of "no account" is confusing you?  While OAuth is better than
having to create yet another bloody account, the whole concept of
requiring one just to enable sending a bug report is completely wrong.


"Sir, I can't help noticing that your fly's open, you might want to
close it."

"Please register as my personal attire adviser or alternatively use your
existing registration with <list elided>. Then come back, show proof of
registration and tell me again."

"Never mind."



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > "Sir, I can't help noticing that your fly's open, you might want to
  > close it."

  > "Please register as my personal attire adviser or alternatively use your
  > existing registration with <list elided>. Then come back, show proof of
  > registration and tell me again."

  > "Never mind."

My thoughts exactly, but you have expressed it better than I would
have.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Stefan Monnier]

>> You need an account if you want to write a new bug report ("issue") in
>> Gitlab, even for public projects. No problem for Emacs developers, they
>> will have an account on Emacs' Gitlab stanza. But we will miss bug
>> reports from Emacs users, which usually have no account there.
> It has OAuth support, users could log in using an account from a number of
> popular services. So that should be a non-issue.

I don't think that's good enough.

Maybe we could do the following:

1- Get a new Gitlab feature which allows anonymous users to subscribe
   arbitrary email addresses to an issue.

2- Then we can build an email gateway from bug-gnu-emacs to Gitlab which
   adds the bug report (under some "gateway-bot" user) as a new issue and
   then subscribes the original submitter's email so they get an email
   copy on any activity to the bug.

3- Presumably any such email-copy comes with a specially crafted "From:"
   address such that replying to that email adds the reply as a comment
   in the issue.

I don't know if Gitlab has feature (3) already, but Github does so
I presume that it's not a problematic feature.

As for feature (1), while I understand that authentication is usually
necessary to reduce the risks of abuse, I think that such a feature
would be fairly low-risk (not much higher than the risk associated to
allowing anyone with a working email address to register).


        Stefan

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

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

> Maybe we could do the following:
>
> 1- Get a new Gitlab feature which allows anonymous users to subscribe
>    arbitrary email addresses to an issue.
>
> 2- Then we can build an email gateway from bug-gnu-emacs to Gitlab which
>    adds the bug report (under some "gateway-bot" user) as a new issue and
>    then subscribes the original submitter's email so they get an email
>    copy on any activity to the bug.
>
> 3- Presumably any such email-copy comes with a specially crafted "From:"
>    address such that replying to that email adds the reply as a comment
>    in the issue.
>
> I don't know if Gitlab has feature (3) already, but Github does so
> I presume that it's not a problematic feature.

Yup; I think we have to have this if Gitlab is to be a usable solution
for Emacs.

> As for feature (1), while I understand that authentication is usually
> necessary to reduce the risks of abuse, I think that such a feature
> would be fairly low-risk (not much higher than the risk associated to
> allowing anyone with a working email address to register).

This reminds me of something that I've been meaning to ask -- how come
there's absolutely no spam on debbugs?  Presumably all the 40K debbugs
addresses are in all the spammers' address books, so the server should
be flooded by spam, but nothing makes it through.  What's the spam
handling system employed by GNU?

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[David Engster]

Lars Ingebrigtsen writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Maybe we could do the following:
>>
>> 1- Get a new Gitlab feature which allows anonymous users to subscribe
>>    arbitrary email addresses to an issue.
>>
>> 2- Then we can build an email gateway from bug-gnu-emacs to Gitlab which
>>    adds the bug report (under some "gateway-bot" user) as a new issue and
>>    then subscribes the original submitter's email so they get an email
>>    copy on any activity to the bug.
>>
>> 3- Presumably any such email-copy comes with a specially crafted "From:"
>>    address such that replying to that email adds the reply as a comment
>>    in the issue.
>>
>> I don't know if Gitlab has feature (3) already, but Github does so
>> I presume that it's not a problematic feature.
>
> Yup; I think we have to have this if Gitlab is to be a usable solution
> for Emacs.

I'm playing around with SourceHut a bit lately (https://sourcehut.org),
and it supports adding tickets without an existing account via mail, and
for import you can create tickets through its API with an arbitrary
external_id, which could just be an email address. It wouldn't
automatically notify these external_id's on new comments, but the
code[1] looks simple enough that adding such a feature doesn't seem
hard. SourceHut has other things going for it, like its web-interface
not needing JavaScript and the code being AGPLv3 licensed. However, it's
still in alpha and hence not ready for a project like Emacs yet. Also,
it is not a GitHub clone, so people may argue we'd just be switching
from one exotic to system to another.

[1] https://git.sr.ht/~sircmpwn/todo.sr.ht/tree/master/todosrht/tickets.py

> This reminds me of something that I've been meaning to ask -- how come
> there's absolutely no spam on debbugs?  Presumably all the 40K debbugs
> addresses are in all the spammers' address books, so the server should
> be flooded by spam, but nothing makes it through.  What's the spam
> handling system employed by GNU?

I dimly remember spam in debbugs being pretty bad ~10 years ago or
so. Something has happened then, but I also don't know what...

-David

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Óscar Fuentes]

David Engster <deng@randomsample.de> writes:

>> Yup; I think we have to have this if Gitlab is to be a usable solution
>> for Emacs.
>
> I'm playing around with SourceHut a bit lately
> (https://sourcehut.org),

The author of SourceHut participates on a forum that I read often. I'm
pretty sure that he would welcome a list of requirements from Emacs'
maintainers.

>> This reminds me of something that I've been meaning to ask -- how come
>> there's absolutely no spam on debbugs?  Presumably all the 40K debbugs
>> addresses are in all the spammers' address books, so the server should
>> be flooded by spam, but nothing makes it through.  What's the spam
>> handling system employed by GNU?
>
> I dimly remember spam in debbugs being pretty bad ~10 years ago or
> so. Something has happened then, but I also don't know what...

Possibly the same as with emacs-devel, -help, etc: a sophisticated
carbon-based spam filtering system.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Benjamin Riefenstahl]

Hi Dmitry,

Dmitry Gutov writes:
> It has OAuth support, users could log in using an account from a
> number of popular services. So that should be a non-issue.

None of which I have or want to have.  So this is an issue for me.

Just my 0.02€,
benny

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > > You need an account if you want to write a new bug report ("issue") in
  > > Gitlab, even for public projects. No problem for Emacs developers, they
  > > will have an account on Emacs' Gitlab stanza. But we will miss bug
  > > reports from Emacs users, which usually have no account there.

  > It has OAuth support, users could log in using an account from a number 
  > of popular services. So that should be a non-issue.

I don't think we can assume that everyone who uses Emacs and might report
a bug has an OAuth account, or would go ahead and make one for this.
I don't have one.  No GNU activity requires one.

Is it possible to have something run on a GNU server and use one
specific OAuth account to submit various people's Emacs bug reports,
all using a single shared OAuth account?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Tim Cross]

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

I think it would be a good idea if the GNU infrastructure was modified to
also be an OATH2.0/openID provider. These are open standards and there are
a number of open source implementations  (for example
https://github.com/ory/hydra which is Apache 2.0).  It would likely improve
the reliability and security of FSF/GNU IAM infrastructure[*} and enable
users with FSF/GNU identities to use them with approved/authorised identity
consumers.  However, there would likely be some significant architecture
changes required, though this could be done in stages. The side benefit
would be an ethical identity provider that could be used by those who have
a FSF/GNU login.

With regards to the specific question as to whether some form of 'generic'
identity could be used to allow bug reports to be lodged without the need
for the user to have an oauth identity, the answer is yes, this cold be
done. Whether this is a good idea is another question. In general,
'generic' identities are a bad thing and should be avoided (for example,
what would you do if someone were to abuse this identity and script the
logging of large numbers of bogus bug reports? You don't want to disable
the identity as it would adversely impact legitimate use. This does not
mean it cannot be done, only that it would require careful consideration of
such risks.

Personally, I'm not sure why we seem to keep considering this as a 'all or
nothing' solution. Why can we not have the best of both. Have an email
gateway to submit bugs in a similar manner to how it is done now AND a web
interface to log, browse, update issues for those with an oauth2.0
compliant login and who want that level of access? You could even setup the
report bug functionality to use an oauth based form submission if the user
has setup an oauth2 id and fall back to email if they don't.

[*} I don't know anything about FSF/GNU infrastructure or the underlying
architecture. However, I have been involved in a number of IAM projects in
both medium and large organisations and have seen the maintenance and
support benefits of a solid identity provider used by all the applications
in an organisation. I have also seen the challenges, maintenance and
security issues associated with IAM solutions which have developed
'organically' as an organisation has grown.

On Mon, 30 Dec 2019 at 11:17, Richard Stallman <rms@gnu.org> wrote:

> [[[ 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. ]]]
>
>   > > You need an account if you want to write a new bug report ("issue")
> in
>   > > Gitlab, even for public projects. No problem for Emacs developers,
> they
>   > > will have an account on Emacs' Gitlab stanza. But we will miss bug
>   > > reports from Emacs users, which usually have no account there.
>
>   > It has OAuth support, users could log in using an account from a
> number
>   > of popular services. So that should be a non-issue.
>
> I don't think we can assume that everyone who uses Emacs and might report
> a bug has an OAuth account, or would go ahead and make one for this.
> I don't have one.  No GNU activity requires one.
>
> Is it possible to have something run on a GNU server and use one
> specific OAuth account to submit various people's Emacs bug reports,
> all using a single shared OAuth account?
>
> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
>

-- 
regards,

Tim

--
Tim Cross

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

  > I think it would be a good idea if the GNU infrastructure was modified to
  > also be an OATH2.0/openID provider. These are open standards and there are
  > a number of open source implementations

I have to point out that we do not advocate or support "open source".
We advocate free software for the sake of freedom -- a value which
"open source" avoids discussing.  Nearly all source code which is
open source is also free software, but exceptions do exist, so the
other is not relevant to our decusions.

See https://gnu.org/philosophy/open-source-misses-the-point.html
for more explanation of the difference between free software and open
source.  See also https://thebaffler.com/salvos/the-meme-hustler for
Evgeny Morozov's article on the same point.

  >   It would likely improve
  > the reliability and security of FSF/GNU IAM infrastructure[*}

That is an issue for sysadmins to think about, not me.

								  and enable
  > users with FSF/GNU identities to use them with approved/authorised identity
  > consumers.

I will not authorize anyone to consume my identity!  No way!

That is a joke but HHOS.  See
https://gnu.org/philosophy/words-to-avoid.html#Consume for why
we reject the word "consume" as a term for doing something with data.

  > The side benefit
  > would be an ethical identity provider that could be used by those who have
  > a FSF/GNU login.

Here we get to the heart of this matter.  Is that a good thing to do?
Or a bad thing to do?  I don't know enough to have an opinion on the
matter, but it is clear that I shouldn't agree to that without first
studying it enough to have an opinion.

Since I have lots of other things on the table, I'd rather put that off.

  > In general,
  > 'generic' identities are a bad thing and should be avoided (for example,
  > what would you do if someone were to abuse this identity and script the
  > logging of large numbers of bogus bug reports? You don't want to disable
  > the identity as it would adversely impact legitimate use.

Right now anyone can send mail dummy bug reports to bug-gnu-emacs.
It doesn't seem to be a big problem in practice, so I think we don't
need to worry about the issue.

  > Have an email
  > gateway to submit bugs in a similar manner to how it is done now AND a web
  > interface to log, browse, update issues for those with an oauth2.0
  > compliant login and who want that level of access? You could even setup the
  > report bug functionality to use an oauth based form submission if the user
  > has setup an oauth2 id and fall back to email if they don't.

I don't see any reason to object to that.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> You need an account if you want to write a new bug report ("issue") in
> Gitlab, even for public projects. No problem for Emacs developers, they
> will have an account on Emacs' Gitlab stanza. But we will miss bug
> reports from Emacs users, which usually have no account there.

Yes, that's a showstopper (and would make it impossible to import the
old bugs).  I was thinking we'd just have an "open" general user for
"anonymous" (i.e., all of the ones not from the web page) submissions.

Would that be problematic?

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> You need an account if you want to write a new bug report ("issue") in
>> Gitlab, even for public projects. No problem for Emacs developers, they
>> will have an account on Emacs' Gitlab stanza. But we will miss bug
>> reports from Emacs users, which usually have no account there.
>
> Yes, that's a showstopper (and would make it impossible to import the
> old bugs).  I was thinking we'd just have an "open" general user for
> "anonymous" (i.e., all of the ones not from the web page) submissions.
>
> Would that be problematic?

We could not identify the author. All bugs would have the same one, with
the same email address. Discussions (with automated email replies)
wouldn't work.

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> We could not identify the author. All bugs would have the same one, with
> the same email address. Discussions (with automated email replies)
> wouldn't work.

Oh, a Gitlab user is tied to a specific email address across all issues?
I was hoping that there was a pre-issue email address.  (And
per-comment.)

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> We could not identify the author. All bugs would have the same one, with
>> the same email address. Discussions (with automated email replies)
>> wouldn't work.
>
> Oh, a Gitlab user is tied to a specific email address across all issues?
> I was hoping that there was a pre-issue email address.  (And
> per-comment.)

Well, I'm using the ghub package from Melpa for my tests. Here you can
see some data for the Emacs project on emba.gnu.org:

--8<---------------cut here---------------start------------->8---
;; Return my user data. I have added my credentials to auth-sources
;; under the name `emba'.

(glab-get "/user" nil :auth 'emba)
==> ((id . 9)
     (name . "Michael Albinus")
     (username . "albinus")
     (state . "active")
     (avatar_url . "https://secure.gravatar.com/avatar/bcd500852e5b9a338e6ac7012a7123cc?s=80&d=identicon")
     (web_url . "https://emba.gnu.org/albinus")
     (created_at . "2019-01-01T16:29:49.344Z")
     (bio)
     (location)
     (public_email . "")
     (skype . "")
     (linkedin . "")
     (twitter . "")
     (website_url . "")
     (organization)
     (last_sign_in_at . "2019-11-19T13:22:55.640Z")
     (confirmed_at . "2019-01-01T16:32:18.477Z")
     (last_activity_on . "2019-11-20")
     (email . "michael.albinus@gmx.de")
     (theme_id . 2)
     (color_scheme_id . 1)
     (projects_limit . 100000)
     (current_sign_in_at . "2019-11-20T09:10:36.839Z")
     (identities)
     (can_create_group . t)
     (can_create_project . t)
     (two_factor_enabled)
     (external)
     (private_profile)
     (is_admin . t))
--8<---------------cut here---------------end--------------->8---

You see, an account has an email address and a public email
address. That's it.

An issue looks like

--8<---------------cut here---------------start------------->8---
;; Return all issues for project 1 (Emacs). No authentication needed.

(glab-get "/projects/1/issues?scope=all" nil :auth 'none)
==> (((id . 1)
      (iid . 1)
      (project_id . 1)
      (title . "Test Test Test")
      (description . "This is a test issue")
      (state . "opened")
      (created_at . "2019-05-08T00:02:19.159Z")
      (updated_at . "2019-11-20T09:11:03.528Z")
      (closed_at)
      (closed_by)
      (labels)
      (milestone)
      (assignees)
      (author
       (id . 13)
      (name . "Dmitry Gutov")
       (username . "dgutov")
       (state . "active")
       (avatar_url . "https://secure.gravatar.com/avatar/15a41553cc73e877f5809c1a9bde8eef?s=80&d=identicon")
       (web_url . "https://emba.gnu.org/dgutov"))
      (assignee)
      (user_notes_count . 1)
      (merge_requests_count . 0)
      (upvotes . 0)
      (downvotes . 0)
      (due_date)
      (confidential)
      (discussion_locked)
      (web_url . "https://emba.gnu.org/emacs/emacs/issues/1")
      (time_stats
       (time_estimate . 0)
       (total_time_spent . 0)
       (human_time_estimate)
       (human_total_time_spent))
      (task_completion_status
       (count . 0)
       (completed_count . 0))
      (has_tasks)
      (_links
       (self . "https://emba.gnu.org/api/v4/projects/1/issues/1")
       (notes . "https://emba.gnu.org/api/v4/projects/1/issues/1/notes")
       (award_emoji . "https://emba.gnu.org/api/v4/projects/1/issues/1/award_emoji")
       (project . "https://emba.gnu.org/api/v4/projects/1"))))
--8<---------------cut here---------------end--------------->8---

Currently, there is only one issue. Theauthor, Dmitry i this case, is
referenced by his id 13. Communication will use this information, and
messages will be send to the email address of this user.

For comments it is similar. There exist one comment, user_notes_count is 1.
Retrieving the data is given as exercise to the reader :-)

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> Currently, there is only one issue. Theauthor, Dmitry i this case, is
> referenced by his id 13. Communication will use this information, and
> messages will be send to the email address of this user.

Right.  So importing old bug reports in a sensible manner is pretty much
impossible with such a setup.  Gitlab would have to grow some
denormalisation in its database for us to be able to use it.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 20.11.2019 13:49, Lars Ingebrigtsen wrote:
> Michael Albinus <michael.albinus@gmx.de> writes:
> 
>> Currently, there is only one issue. Theauthor, Dmitry i this case, is
>> referenced by his id 13. Communication will use this information, and
>> messages will be send to the email address of this user.
> 
> Right.  So importing old bug reports in a sensible manner is pretty much
> impossible with such a setup.  Gitlab would have to grow some
> denormalisation in its database for us to be able to use it.

We could ask everybody here to create an account. Maybe even send out 
such requests personally for people who had been active in the past. And 
then, when doing the import, try to assign comments to existing accounts 
going by email.

The rest would probably have to be imported as created by some utility 
user (to use an example from a popular Russian online community, we 
could call it UFO), and the authors would not get notifications for any 
new replies (unless notified by email personally as well).

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> We could ask everybody here to create an account. Maybe even send out
> such requests personally for people who had been active in the
> past. And then, when doing the import, try to assign comments to
> existing accounts going by email.

If we would go this way (for example, with emba.gnu.org), I would expect
that all members of the emacs project on savannah will be populated
automatically on emba.

I don't know how users are managed on savannah, but GitLab integrates
with LDAP to support user authentication, for example.

> The rest would probably have to be imported as created by some utility
> user (to use an example from a popular Russian online community, we
> could call it UFO), and the authors would not get notifications for
> any new replies (unless notified by email personally as well).

I don't like this approach, honestly. We would have a feature
regression, compared with debbugs. I thought, we are working on
improvements.

And it doesn't solve the problem of reporting new bugs to Emacs by users
with no account.

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 20.11.2019 15:55, Michael Albinus wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> We could ask everybody here to create an account. Maybe even send out
>> such requests personally for people who had been active in the
>> past. And then, when doing the import, try to assign comments to
>> existing accounts going by email.
> 
> If we would go this way (for example, with emba.gnu.org), I would expect
> that all members of the emacs project on savannah will be populated
> automatically on emba.
> 
> I don't know how users are managed on savannah, but GitLab integrates
> with LDAP to support user authentication, for example.

That should work, yes.

>> The rest would probably have to be imported as created by some utility
>> user (to use an example from a popular Russian online community, we
>> could call it UFO), and the authors would not get notifications for
>> any new replies (unless notified by email personally as well).
> 
> I don't like this approach, honestly. We would have a feature
> regression, compared with debbugs. I thought, we are working on
> improvements.

Not on improvements to Debbugs, though.

But, okay, we could also pre-create accounts for every email that has 
ever graced our presence on Debbugs. Then the users could do password 
recovery and voila.

I'm not quite sure how this approach would interact with external 
authentication, though (like when an email is @gmail.com, and the user 
would prefer to authenticate against Google's account database).

> And it doesn't solve the problem of reporting new bugs to Emacs by users
> with no account.

I'm fairly sure every such issue can be fixed, given sufficient effort. 
This one doesn't seem like a big priority to me. Most people already 
have an account *somewhere*. The others can spend a couple of minutes on 
registration. Anybody who's going to argue otherwise will most certainly 
spend more time arguing their position than such registration would take.

Someone said that we'd lose on some bug reports this way. Yes, we will. 
We lose out on many more bug reports anyway by refusing to migrate off 
Debbugs.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> I don't like this approach, honestly. We would have a feature
>> regression, compared with debbugs. I thought, we are working on
>> improvements.
>
> Not on improvements to Debbugs, though.

Not in general. But as long as we haven't switched, I won't stop to add
features to debbugs{,-gnu}.el.

That doesn't mean I believe it is the best tool to be used. And I don't
object to switch somewhere else. But debbugs is what's working now, and
it will still take time before we switch. If ever.

Best regards, Michael.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> But, okay, we could also pre-create accounts for every email that has
> ever graced our presence on Debbugs. Then the users could do password 
> recovery and voila.

Hm...  I'm not sure I totally like that idea.  Creating accounts on
behalf of other people seems...  coercive, somehow.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 21.11.2019 13:57, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> But, okay, we could also pre-create accounts for every email that has
>> ever graced our presence on Debbugs. Then the users could do password
>> recovery and voila.
> 
> Hm...  I'm not sure I totally like that idea.  Creating accounts on
> behalf of other people seems...  coercive, somehow.

It's a frequent practice, but often a marketing move, so it might feel 
kind of dirty to us techies.

Then, and this is an option that will request less up-front effort, we 
can go with the "UFO" approach, and then anybody doing spelunking in the 
old issues would follow the link to the original report and directly 
email the author with a follow-up question (and ask them to register 
only then).

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Then, and this is an option that will request less up-front effort, we
> can go with the "UFO" approach, and then anybody doing spelunking in
> the old issues would follow the link to the original report and
> directly email the author with a follow-up question (and ask them to
> register only then).

I don't think we should accept moving to a new system that's (much)
worse than the old system (for any usage), and this is a serious
regression, in my opinion.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 21.11.2019 17:14, Lars Ingebrigtsen wrote:
> I don't think we should accept moving to a new system that's (much)
> worse than the old system (for any usage), and this is a serious
> regression, in my opinion.

It only a problem for old bug reports.

And how often, really, do you get new, valuable info from reporters who 
filed a bug years ago, where nothing has happened in the meantime?

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> It only a problem for old bug reports.

Well, there's a lot of them.

> And how often, really, do you get new, valuable info from reporters
> who filed a bug years ago, where nothing has happened in the meantime?

Often.  Probably not the majority of them (because they've stopped using
Emacs etc), but for the people still with us, it's vital. 

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 21 Nov 2019 16:20:19 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
>  "Perry E. Metzger" <perry@piermont.com>,
>  Michael Albinus <michael.albinus@gmx.de>, Richard Stallman <rms@gnu.org>,
>  emacs-devel@gnu.org
> 
> > And how often, really, do you get new, valuable info from reporters
> > who filed a bug years ago, where nothing has happened in the meantime?
> 
> Often.  Probably not the majority of them (because they've stopped using
> Emacs etc), but for the people still with us, it's vital. 

Right.  Just look at bug-gnu-emacs lately (thanks to Lars, Stefan, and
others): many old bug reports were dusted off, and their OP asked
whether the problem still existed in the current master.
Surprisingly, a vast majority of them responded with valuable
information.

Once again, I think we need to talk to GitLab developers about this.
It makes no sense not to have a solution for this issue.  Maybe there
already is one, just not widely known or documented.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Stefan Monnier]

> Once again, I think we need to talk to GitLab developers about this.
> It makes no sense not to have a solution for this issue.  Maybe there
> already is one, just not widely known or documented.

I think the only thing we need is to be able to subscribe arbitrary
email addresses to an issue (instead of being limited to subscribing
users known to Gitlab).  I think it's a valuable functionality in
any case.


        Stefan

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 21 Nov 2019 10:52:31 -0500
> Cc: ofv@wanadoo.es, rms@gnu.org, emacs-devel@gnu.org, michael.albinus@gmx.de,
>  dgutov@yandex.ru, Lars Ingebrigtsen <larsi@gnus.org>, perry@piermont.com
> 
> > Once again, I think we need to talk to GitLab developers about this.
> > It makes no sense not to have a solution for this issue.  Maybe there
> > already is one, just not widely known or documented.
> 
> I think the only thing we need is to be able to subscribe arbitrary
> email addresses to an issue (instead of being limited to subscribing
> users known to Gitlab).  I think it's a valuable functionality in
> any case.

I think we need to explain to them what are our needs, and leave it up
to them to suggest the technical solution.  All we need is to be able
to indicate the person who submitted the original report in a way that
this person will be notified of any activities in the issue.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

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

Given that we record the OP's email address, automatically making an
account whose name is simply that email address (perhaps munged) would
not capture or record any additional personal info.  So I think there would
be no wrong in doing so.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> I don't like this approach, honestly. We would have a feature
> regression, compared with debbugs. I thought, we are working on
> improvements.

Indeed.  I don't see any reason why an issue tracker like Gitlab's
couldn't have a denormalised system where each issue/comment can refer
to a separate email.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Wed, 20 Nov 2019 12:39:56 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org,
>  Richard Stallman <rms@gnu.org>, "Perry E. Metzger" <perry@piermont.com>
> 
> You see, an account has an email address and a public email
> address. That's it.

Does that mean that no project yet had to deal with the task of
importing their old bug database?  That sounds very strange to me.
Maybe someone should ask GitLab developers about this?

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Yuri Khan]

On Wed, 20 Nov 2019 at 23:29, Eli Zaretskii <eliz@gnu.org> wrote:

> Does that mean that no project yet had to deal with the task of
> importing their old bug database?  That sounds very strange to me.
> Maybe someone should ask GitLab developers about this?

The GNOME project migrated from Bugzilla some time ago. The general
scheme of migration was:

* The target GitLab instance has a dedicated “bugzilla-migration” user
account (the “UFO” Dmitry mentioned).
* For each bug in the source Bugzilla instance, a new GitLab issue is
created by the bugzilla-migration user, with a link to the original
Bugzilla bug, a copy of the bug description, and a reference to the
original bug author.
* For each comment to the original bug, a new comment in the migrated
issue is also created by the bugzilla-migration user, with a copy of
the comment and a reference to the comment author.
* The original bug gets a new comment with an explanation of the
migration and a link to the migrated issue. Each user who was
subscribed to the original bug gets a copy of this comment, and can go
register at the target GitLab instance and re-subscribe to the
migrated issue at his/her leisure.

An example of a migrated bug/issue:

https://bugzilla.gnome.org/show_bug.cgi?id=766142
https://gitlab.gnome.org/GNOME/gnome-sudoku/issues/25

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 21 Nov 2019 02:27:28 +0700
> Cc: Michael Albinus <michael.albinus@gmx.de>, Óscar Fuentes <ofv@wanadoo.es>, 
> 	Lars Magne Ingebrigtsen <larsi@gnus.org>, perry@piermont.com, rms@gnu.org, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> The GNOME project migrated from Bugzilla some time ago. The general
> scheme of migration was:
> 
> * The target GitLab instance has a dedicated “bugzilla-migration” user
> account (the “UFO” Dmitry mentioned).
> * For each bug in the source Bugzilla instance, a new GitLab issue is
> created by the bugzilla-migration user, with a link to the original
> Bugzilla bug, a copy of the bug description, and a reference to the
> original bug author.
> * For each comment to the original bug, a new comment in the migrated
> issue is also created by the bugzilla-migration user, with a copy of
> the comment and a reference to the comment author.
> * The original bug gets a new comment with an explanation of the
> migration and a link to the migrated issue. Each user who was
> subscribed to the original bug gets a copy of this comment, and can go
> register at the target GitLab instance and re-subscribe to the
> migrated issue at his/her leisure.
> 
> An example of a migrated bug/issue:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=766142
> https://gitlab.gnome.org/GNOME/gnome-sudoku/issues/25

Thanks, but I don't understand what that means in practice, when an
old bug is worked on after the migration.  Is the original author of
the bug report subscribed to the correspondence about the bug after
the migration, or does he/she need to actively subscribe to it?  If
the latter, I don't think the solution is satisfactory.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Yuri Khan]

On Thu, 21 Nov 2019 at 02:31, Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks, but I don't understand what that means in practice, when an
> old bug is worked on after the migration.  Is the original author of
> the bug report subscribed to the correspondence about the bug after
> the migration, or does he/she need to actively subscribe to it?  If
> the latter, I don't think the solution is satisfactory.

I do believe it was the latter, and I think it’s not a big deal in
practice. The authors got due notice.

In theory, it should be possible to pre-create user accounts for each
known email address, and do a perfect migration “as if” GitLab had
always existed and been in use. Maybe even doctor the comments so as
to strip excessive quoting if any, and mark up patches as code blocks.
(The same idea as ESR does any-version-control-system-to-Git
conversions.)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Robert Pluim]

>>>>> On Thu, 21 Nov 2019 02:44:58 +0700, Yuri Khan <yuri.v.khan@gmail.com> said:

    Yuri> In theory, it should be possible to pre-create user accounts for each
    Yuri> known email address, and do a perfect migration “as if” GitLab had
    Yuri> always existed and been in use. Maybe even doctor the comments so as
    Yuri> to strip excessive quoting if any, and mark up patches as code blocks.
    Yuri> (The same idea as ESR does any-version-control-system-to-Git
    Yuri> conversions.)

pre-create accounts based on Personally Identifiable Information?
Without explicit approval from the concerned person?  Welcome to
various Europeans sending you nasty letters with GDPR threats sprayed
all over them.

Robert

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Dmitry Gutov]

On 20.11.2019 21:31, Eli Zaretskii wrote:
> Is the original author of
> the bug report subscribed to the correspondence about the bug after
> the migration, or does he/she need to actively subscribe to it? If
> the latter, I don't think the solution is satisfactory.

The latter, yes. But I'm more hopeful about this solution. What are we 
worried about?

That when we write to old bugs again, the submitter won't receive the 
comments? At that point, they'd have to ignore at least one email from 
us. And if we really want to ask them again later, we could do that 
manually.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> Cc: ofv@wanadoo.es, rms@gnu.org, emacs-devel@gnu.org, michael.albinus@gmx.de,
>  larsi@gnus.org, perry@piermont.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 20 Nov 2019 21:46:26 +0200
> 
> On 20.11.2019 21:31, Eli Zaretskii wrote:
> > Is the original author of
> > the bug report subscribed to the correspondence about the bug after
> > the migration, or does he/she need to actively subscribe to it? If
> > the latter, I don't think the solution is satisfactory.
> 
> The latter, yes. But I'm more hopeful about this solution. What are we 
> worried about?

That they won't subscribe.

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> The latter, yes. But I'm more hopeful about this solution. What are we
> worried about?
>
> That when we write to old bugs again, the submitter won't receive the
> comments?

Yes.  As someone who goes spelunking into bug reports, it would be a
major problem if questions I have about the reported bugs do not reach
the person who reported the bug.

And requesting somebody to register as a user on Gitlab seven years
after reporting an Emacs bug "just in case" somebody might actually take
a look at their bug report sounds horribly rude to me.

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Stefan Kangas]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > The latter, yes. But I'm more hopeful about this solution. What are we
> > worried about?
> >
> > That when we write to old bugs again, the submitter won't receive the
> > comments?
>
> Yes.  As someone who goes spelunking into bug reports, it would be a
> major problem if questions I have about the reported bugs do not reach
> the person who reported the bug.

Having done a bit of bug triaging lately, I wanted to jump in and say that
I fully agree with this.  In many cases, we have no one but the original
reporter to provide us with the information we need to make any progress.
Making it harder to quickly ask the reporter for more information would
risk slowing down bug triaging significantly, at least in my use cases.

> And requesting somebody to register as a user on Gitlab seven years
> after reporting an Emacs bug "just in case" somebody might actually take
> a look at their bug report sounds horribly rude to me.

I think it's unrealistic to expect that we would get very good results with
asking people to register.  We can often count ourselves lucky if the
reporter even replies back to our e-mails.  As Eli ponted out we have had
some excellent response using email, but we don't know how that would be
affected if we demanded that someone logged in.  IMO, we need Gitlab to
handle email well and transparently.

Best regards,
Stefan Kangas

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

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Perry E. Metzger]

On Wed, 20 Nov 2019 12:00:10 +0100 Michael Albinus
<michael.albinus@gmx.de> wrote:
> We could not identify the author. All bugs would have the same one,
> with the same email address. Discussions (with automated email
> replies) wouldn't work.

Software is mutable; free software even more so. If it's important
enough to allow random people to submit bug reports, the code can be
modified to make that practical. Saying that it's "impossible" to
use Gitlab because it lacks a feature we could write is unreasonable.
Saying "we will need to add the following feature" is more
constructive.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [Was: bug#25148:])

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

  > > Like it or not, [the Emacs developers] get the priority right
  > > now. Being nice to new users is great, but until they become
  > > contributors and ease our workload, serving them can't be the
  > > priority.

That is a valid position _for tools for Emacs developers_.

The functioning of Emacs is a different area.  There, we
should put some effort into facilitin learning Emacs,
by simplifying interfaces when we can.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> The functioning of Emacs is a different area. There, we should put some
> effort into facilitin learning Emacs, by simplifying interfaces when we can.

I agree completely. Emacs itself should be suited to what works best for the
largest number, and not only the members of emacs-devel. It's the tooling
around it that favors those who use it most right now.

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

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[dick.r.chiang]

I hear you loud and clear on the debbugs, but many people accustomed to
browser-everything would also say emacs is similarly antiquated.

I would be frustrated too by the responses you received suggesting nothing is
awry about debbugs.  But in any unpaid project, the response to "please kill
this" should be "please implement a better alternative."

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Karl Fogel]

On 17 Nov 2019, dick.r.chiang@gmail.com wrote:
>I hear you loud and clear on the debbugs, but many people accustomed to
>browser-everything would also say emacs is similarly antiquated.
>
>I would be frustrated too by the responses you received suggesting nothing is
>awry about debbugs.  But in any unpaid project, the response to "please kill
>this" should be "please implement a better alternative."

Agreed.  I think we've had consensus on that for a long time:

  https://wiki.debian.org/SummerOfCode2007/DebbugsWebUI

:-)

As far as I can tell, everyone is fine with our bug-tracking system having more browser-accessible features -- particularly the features many developers are accustomed to from other trackers -- as long as the system *also* has the email-manipulation capabilities that Debbugs currently has (and on which some of Emacs's most active & expert maintainers depend).

Best regards,
-Karl

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Christopher Lemmer Webber]

Karl Fogel writes:

> On 17 Nov 2019, dick.r.chiang@gmail.com wrote:
>>I hear you loud and clear on the debbugs, but many people accustomed to
>>browser-everything would also say emacs is similarly antiquated.
>>
>>I would be frustrated too by the responses you received suggesting nothing is
>>awry about debbugs.  But in any unpaid project, the response to "please kill
>>this" should be "please implement a better alternative."
>
> Agreed.  I think we've had consensus on that for a long time:
>
>   https://wiki.debian.org/SummerOfCode2007/DebbugsWebUI
>
> :-)
>
> As far as I can tell, everyone is fine with our bug-tracking system
> having more browser-accessible features -- particularly the features
> many developers are accustomed to from other trackers -- as long as
> the system *also* has the email-manipulation capabilities that Debbugs
> currently has (and on which some of Emacs's most active & expert
> maintainers depend).
>
> Best regards,
> -Karl

Guix runs a web based issue tracker on top of debbugs that looks quite
nice:

  https://issues.guix.gnu.org/
  https://issues.guix.gnu.org/issue/37855

The software for the web UI is here:
  https://git.elephly.net/software/mumi.git

It doesn't allow for replying via the web UI, but navigating as a user
is much nicer.  Maybe it will make some people happier?

Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Eli Zaretskii]

> From: Christopher Lemmer Webber <cwebber@dustycloud.org>
> Date: Wed, 20 Nov 2019 11:37:38 -0500
> Cc: Óscar Fuentes <ofv@wanadoo.es>, dick.r.chiang@gmail.com,
>  emacs-devel@gnu.org
> 
> Guix runs a web based issue tracker on top of debbugs that looks quite
> nice:
> 
>   https://issues.guix.gnu.org/
>   https://issues.guix.gnu.org/issue/37855
> 
> The software for the web UI is here:
>   https://git.elephly.net/software/mumi.git
> 
> It doesn't allow for replying via the web UI, but navigating as a user
> is much nicer.  Maybe it will make some people happier?

Thanks.

If such UIs are relevant, maybe people should also take a look at the
Savannah bug tracker, for example:

  https://savannah.gnu.org/bugs/?group=make