Re: Processed: control message for bug #33200

[Garreau\, Alexandre]

On 2018-11-01 at 11:57, Michael Albinus wrote:
> "Garreau, Alexandre" <address@hidden> writes:
>>>> I don't think anybody really uses "owner" much, so it de facto hardly
>>>> means anything.
>>>
>>> If you are using debbugs.el, it might be helpful to read its user
>>> guide. Try (info "(debbugs-ug)")
>>
>> It really ought to have an index.
>
> It's more complicate. The ELPA debbugs package offers two manuals,
> (info "(debbugs-ug)") and (info "(debbugs)") . The former is the user
> guide I have recommended to you, it describes how to interact with
> debbugs-gnu.el (and debbug-org.el, FWIW). The latter guide describes the
> SOAP interface of debbugs.el, which communicates with
> debbugs.gnu.org. It is not relevant for public use; however, it
> describes the attributes in detail. That's why they are not described in
> the debbugs user guide, again. It's an unfortunate situation, and shall
> be improved.

But neither of both has an index, so I can’t quickly find information,
nor could any automatical auto-documentation feature of `debbugs' then.

I believe both should give such information, or only user manual.  It is
important to have somewhere easily accessible a documentation of the
*meaning* of each feature.

>> Hence:
>>
>>> The attribute "owner" is intended to document, who is responsible for
>>> fixing a bug. Usually, you tag a bug with it in order to tell other
>>> people that you are working on the bug. However, in the Emacs community
>>> this is used rarely.
>>
>> This is a neat, unambiguous and formal definition.  Why isn’t it in the
>> aforementioned manual?
>
> I've quoted this from (info "(debbugs) Requesting bugs statuses")

For the first sentence, not the other.  Yet I would have found this out
if there were an index.

>>> Patches welcome!
>>
>> Okay let’s try:
>>
>> +(defcustom debbugs-gnu-confirm-control-messages '("owner")
>> +  "List of control messages asking for confirmation.
>> +Each message listed will make `debbugs-gnu-send-control-message'
>> +ask for confirmation before sending control message mail."
>> +  :type (cons 'set (mapcar (apply-partially #'list 'const)
>> +                           debbugs-gnu-control-messages))
>> +  :group 'debbugs-gnu)
>
> I don't believe whether we need to determine, which attribute needs
> confirmation, and which not. Likely, it is sufficient to have a user
> option
>
> (defcustom debbugs-gnu-confirm-control-messages nil
>   "Whether control messages shall be confirmed prior sending."
>   :type 'boolean
>   :group 'debbugs-gnu)
>
> And then we have
>
>       (when (or debbugs-gnu-confirm-control-messages
>                 (y-or-n-p (format "Really send `%s' control message? "
>                                    message))))

I believe so.  What’s useful here is to put a discrimination between,
first, purely technical common changes that might be anyway reversed by
another message, meaning usually the change reflected the state of the
bug as it should have been since the beginning, and, second, less
technical / more organizational/logistic change whose goal might to
actually reflect user intent, or a change in the bug or people around
it: giving the later impression that this change had any non-technical
actual meaning at all (like “I changed my mind”).  The former doesn’t
need confirmation, because at worse you undo it and in the future it
should be seen as exactely the same.  The later, though it can be
undone, will fill debbugs database with some control messages that will
on one side reflect a change of the bug or user intent, and on the other
sides changes that neither of these but just user error (so, if you
later want to do statistics, they’re more broken).

I also believe when doing an action it is pointless to ask to the user
for confirmation if they already clearly indicated they wanted to do it,
that’d be redundant and annoying for most users… except it just won’t be
used by anybody.  There’s no point in adding an annoyance.

Just the same as, especially is it is an annoyance, but not only, if
it’s not the default: it’s useless to add then.  So if you believe it
would be inacceptable change for most users to require them to set some
custom variable to nil, it’d be better not to change anything at all.
Because the point of a safe-guard is to prevent new, ignorant or
distracted users to do what they don’t want to, but these kind of users
are the most unlikely to be aware about and able to enable this setting
*before* doing the error we want to avoid.  While experienced users,
annoyed by the, for them, useless confirmation, will likely look up the
docstring and/or the manual and disable it right away, without any more
problem.

Just as currently the Emacs welcome help screen is shown by default, and
you need a setting to remove it: because otherwise it is pointless to
hope new users will magically be aware of and enable it to welcome
themselves and make themselves aware of the information this buffer is
meant to give them.

The first category I described before seems to unambiguously include:
patch, invalid, *block, confirmed, easy, serious, important, normal,
minor, wishlist, moreinfo, notabug, security, unreproducible, wontfix,
reassign, retitle (though I am unsure about some of these might in fact
reflect an evolution of the bug or of the suggested fix, in whose case
they’d optionally end in the second category)
 
While in the second I’d now put: help, fixed, close, done*, noowner,
owner.

I am unsure about the meaning of these (the manual says what they are
meant to be, but not what they are for): *forwarded, *merge*, pending.

Anyway I now convinced myselves these actually reflect rich and useful
meaning about debbugs tags and working, so they must have their own
`defconst', revised by you or someone being sure of debbugs semantics
(so it could help clarify and formalize them more), and then either, as
you suggested, a simple custom for “asking confirmation or not”, or one
that would offer as a default and user-proposed option “what to confirm”
to be set to the second category list, or tweaked.

> Bonus, if `message' could come with a help-echo like
>
> (propertize message 'help-echo (debbugs-gnu-help-echo message))
>
> The missing point is to write a proper `debbugs-gnu-help-echo'
> function. Would you like to work on this?

I’d like if I saw the point of it: an echo message is meant to be small,
not mandatory to see (after all, not all people will think to point
everything with the mouse cursor), rather an optional little “help”: I’d
prefer that *will* be seen anyway, in a more clear and obvious place.
So what I initially thought was either getting a prompt suggesting a
“help” answer that explain the control message and prompt again, either
even automatically opening the manual in the place referred in the index
by the control message name, in a small buffer of only 2-3 lines (enough
to display the description of the control message).

But ideally I’d like a such function to be linked with the manual, so to
remove redundancy, and that’d require an index.

The other option would be to make one command per message (at least this
way it might become easier to bind to keys), recopy manual excerpts in
the docstrings, and display the docstrings instead (so its proper
working wouldn’t be dependent on whether the manual is installed).

>> Would that be okay? just to know, so I learn if then I report a real bug
>> (or, since it’s more an improvement wishlist, maybe doesn’t it need to
>> be reported as a bug?).
>
> Wishlists are also reported as a bug. They have the severity `wishlist' :-)

I knew that, just wanted to know if that was an optional feature to
better describe meta-data about already (maybe wrongly so) reported bug,
if it was to do with all feature requests.

>>> Usually, you tag a bug with it in order to tell other people that you
>>> are working on the bug. However, in the Emacs community this is used
>>> rarely.
>>
>> So, I tried to propose a patch (to gnus), this was my first attempt.  So
>> I’d like to “work on it” if I can, but I don’t want to indicate I’m
>> knowledgeful enough to fully and surely be able to do it all alone:
>> should I stay “owner”?  if I “noowner”, am I not (falsely) indicating I
>> am not willing to “work on it” anymore?
>
> No, you don't indicate this. Setting "owner" simply says to other people
> that they don't need to care. If you remove this attribute, you still
> could continue to work on the problem, but you don't say "no help needed".

Okay, then, if I want to work on it, but I likely might need help, I
should noowner myself?

Also is it meaningful for someone not able to apply patches yet to be
owner of a bug?

That are the kind of informations that would be useful in the debbugs
manual.

>>> Bug reports about the debbugs ELPA package shall go to Emacs, "M-x
>>> report-emacs-bug" as usual.
>>
>> No really?  aren’t elpa package maintained on their own?
>
> There's no formal rule about. However, it is accepted that bug reports
> for GNU ELPA packages are reported towards Emacs. For other packages,
> for example from MELPA, this is not the case.
>
> […]
>
> It is his own decision, of course. And he is also right about the
> emacs-devel ML. But I don't see a problem if this would be discussed as
> debbugs bug.

Okay, I’ll say him and keep as is then, thank you!