bug#33005: 27.0.50; Data loss with Gnus registry

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Michael Heerdegen

Hello,

I want to use the Gnus registry to use registry marks and store data as
described in (info "(gnus) Store arbitrary data").  Very often, these
things vanish after restarting Emacs or Gnus.

For example, I use M M i to mark some article "Important".  I have
configured `gnus-summary-line-format' to show registry marks.  Often,
after restarting, the mark is gone.  Likewise, data stored with
`gnus-registry-set-id-key' gets lost, even when the according article
has a registry mark attached.

[BTW, there is a typo in (info "(gnus) Store arbitrary data").  It says
`gnus-registry-extra-entries-precious' would default to (marks) but it
defaults to (mark)]

My final goal is to implement a little Gnu Elpa package
"gnus-article-notes.el" that can be used to attach little text notes to
arbitrary articles.  The package is already done, if you are interested,
I can send you the code.  I have verified that registry marks get lost
independently of that package.  I guess there is something wrong with
registry pruning.  CC'ing Eric Abrahamsen who has recently worked in
this area.


TIA,

Michael.




In GNU Emacs 27.0.50 (build 14, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
 of 2018-10-10 built on drachen
Repository revision: db1daee25ae82cdd1e0b7a8f50fa55003f31cf67
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: Debian GNU/Linux buster/sid

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS GLIB NOTIFY
GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM
THREADS JSON LCMS2 GMP




Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Eric Abrahamsen-2
Michael Heerdegen <[hidden email]> writes:

> Hello,
>
> I want to use the Gnus registry to use registry marks and store data as
> described in (info "(gnus) Store arbitrary data").  Very often, these
> things vanish after restarting Emacs or Gnus.
>
> For example, I use M M i to mark some article "Important".  I have
> configured `gnus-summary-line-format' to show registry marks.  Often,
> after restarting, the mark is gone.  Likewise, data stored with
> `gnus-registry-set-id-key' gets lost, even when the according article
> has a registry mark attached.
>
> [BTW, there is a typo in (info "(gnus) Store arbitrary data").  It says
> `gnus-registry-extra-entries-precious' would default to (marks) but it
> defaults to (mark)]

There were some bugs with registry pruning and precious entries, but
we fixed those quite a while ago. If you're running Emacs master, you
should have the Gnus that incorporates those fixes. On the other hand,
what you say above about the docstring makes me wonder, as in Gnus
master it doesn't say it would default to (marks). You're not loading an
external Gnus installation, are you?

Eric



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Michael Heerdegen
Eric Abrahamsen <[hidden email]> writes:

> There were some bugs with registry pruning and precious entries, but
> we fixed those quite a while ago. If you're running Emacs master, you
> should have the Gnus that incorporates those fixes.

Yes, I think so, too.  I have a normal recent Emacs master build.  I
typically rebuild daily.

> On the other hand, what you say above about the docstring makes me
> wonder, as in Gnus master it doesn't say it would default to
> (marks). You're not loading an external Gnus installation, are you?

No, I'm not.  In emacs master branch, "doc/misc/gnus.texi" says

  "default this is just @code{(marks)} so the custom registry marks are"

in line 26197.  Not for you?



Michael.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Eric Abrahamsen-2
Michael Heerdegen <[hidden email]> writes:

> Eric Abrahamsen <[hidden email]> writes:
>
>> There were some bugs with registry pruning and precious entries, but
>> we fixed those quite a while ago. If you're running Emacs master, you
>> should have the Gnus that incorporates those fixes.
>
> Yes, I think so, too.  I have a normal recent Emacs master build.  I
> typically rebuild daily.
>
>> On the other hand, what you say above about the docstring makes me
>> wonder, as in Gnus master it doesn't say it would default to
>> (marks). You're not loading an external Gnus installation, are you?
>
> No, I'm not.  In emacs master branch, "doc/misc/gnus.texi" says
>
>   "default this is just @code{(marks)} so the custom registry marks are"
>
> in line 26197.  Not for you?

Sorry, I was looking at the option docstring, not the manual. I'll fix
that typo.

But that was my only easy solution, unfortunately. You could examine the
results of:

(registry-collect-prune-candidates gnus-registry-db
(registry-size gnus-registry-db) nil)

To verify that it is returning candidates that should not be returned.
Unfortunately that function uses `cl-loop', which makes edebugging not
very helpful.

Shameless plug: I'm about to propose a new package called "gnus-mock",
which sets up a temporary/trashable/reproducible Gnus installation that
you can use for testing feature and hunting bugs, without endangering
your own Gnus data. That would be useful in this case. I might have it
done today.

Eric



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Michael Heerdegen
Eric Abrahamsen <[hidden email]> writes:

> But that was my only easy solution, unfortunately. You could examine the
> results of:
>
> (registry-collect-prune-candidates gnus-registry-db
> (registry-size gnus-registry-db) nil)

Ok, I'll try that.

> Shameless plug: I'm about to propose a new package called "gnus-mock",
> which sets up a temporary/trashable/reproducible Gnus installation that
> you can use for testing feature and hunting bugs, without endangering
> your own Gnus data.

Yes, that's sounds exactly like the thing I wanted :-)


Michael.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Michael Heerdegen
In reply to this post by Eric Abrahamsen-2
Eric Abrahamsen <[hidden email]> writes:

> (registry-collect-prune-candidates gnus-registry-db
> (registry-size gnus-registry-db) nil)

Ok, I managed to debug this.

The entry is indeed pruned.  It looks like

Key:  "<153...>"

Value: ((mark Important) (subject ...) ...)

In the `registry-collect-prune-candidates' method, the variable PRECIOUS
is bound to the list (gnorb-ids org-tags mark).

AFAIU, since PRECIOUS-P is defined as

  (lambda (entry-key) (cdr (memq (car-safe entry-key) precious)))

and the symbol mark comes last in the PRECIOUS list, the `cdr' of the
`memq' call is nil.  If I remove the `cdr' call, the entry isn't pruned
any more.  I also don't get why that `cdr' is there.  Or is my value of
PRECIOUS illegal?


Michael.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Eric Abrahamsen-2

On 10/10/18 23:24 PM, Michael Heerdegen wrote:

> Eric Abrahamsen <[hidden email]> writes:
>
>> (registry-collect-prune-candidates gnus-registry-db
>> (registry-size gnus-registry-db) nil)
>
> Ok, I managed to debug this.
>
> The entry is indeed pruned.  It looks like
>
> Key:  "<153...>"
>
> Value: ((mark Important) (subject ...) ...)
>
> In the `registry-collect-prune-candidates' method, the variable PRECIOUS
> is bound to the list (gnorb-ids org-tags mark).
>
> AFAIU, since PRECIOUS-P is defined as
>
>   (lambda (entry-key) (cdr (memq (car-safe entry-key) precious)))
>
> and the symbol mark comes last in the PRECIOUS list, the `cdr' of the
> `memq' call is nil.  If I remove the `cdr' call, the entry isn't pruned
> any more.  I also don't get why that `cdr' is there.  Or is my value of
> PRECIOUS illegal?

Nice work! I have no idea why that `cdr' is in there, and as the value
is used as a boolean it seems totally superfluous. I don't use registry
marks, which is probably the reason I never noticed (I didn't write this
code).

I don't see any reason not to remove the `cdr', and will do so unless
someone objects cogently, soon.

Thanks,
Eric



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Michael Heerdegen
Eric Abrahamsen <[hidden email]> writes:

> Nice work! I have no idea why that `cdr' is in there, and as the value
> is used as a boolean it seems totally superfluous. I don't use registry
> marks, which is probably the reason I never noticed (I didn't write this
> code).

Looks like the code has been like that from the beginning: ccd58722df
"Add lisp/gnus/registry.el.", Ted Zlatanov, Tue Apr 5 23:37:02 2011
introduces the file (it has been moved once since then), and the code is
already the same there.

I can only guess that the intention could have been to distinguish (mark) from
(mark SOMETHING): prune the first because the mark field is empty.
Anyway, seems it never worked like that.


Michael.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Michael Heerdegen
Michael Heerdegen <[hidden email]> writes:

> Anyway, seems it never worked like that.

But what's even more frightening: The default value of
`gnus-registry-extra-entries-precious', (mark), always behaved like ()
and thus never worked as intended, so it seems that registry marks
always where broken with the defaults.  Looks like nobody ever tried to
use them, or all people gave up without writing a bug report.

Should we even make a NEWS entry along the fix saying that the feature
can actually be used now?


Michael.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Eric Abrahamsen-2

On 10/11/18 15:10 PM, Michael Heerdegen wrote:
> Michael Heerdegen <[hidden email]> writes:
>
>> Anyway, seems it never worked like that.
>
> But what's even more frightening: The default value of
> `gnus-registry-extra-entries-precious', (mark), always behaved like ()
> and thus never worked as intended, so it seems that registry marks
> always where broken with the defaults.  Looks like nobody ever tried to
> use them, or all people gave up without writing a bug report.

I don't think very many people use the registry, or at least, they
aren't using it intentionally to store their own information.

> Should we even make a NEWS entry along the fix saying that the feature
> can actually be used now?

I don't think so, bug fixes don't usually get a NEWS entry. But I can
say something on the gnus.general list.

Also, I really like the idea of using the registry to attach notes to
mails -- that's something I've intended for Gnorb for a while. If you'd
like to contribute that to Gnorb I'd be very happy to accept it, or
maybe it's something that could even go into the registry proper. Of
course, if you'd prefer to keep it a separate package that's fine too --
I'd install it!

Thanks,
Eric



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Eli Zaretskii
In reply to this post by Eric Abrahamsen-2
> From: Eric Abrahamsen <[hidden email]>
> Date: Wed, 10 Oct 2018 16:05:50 -0700
> Cc: [hidden email]
>
> I don't see any reason not to remove the `cdr', and will do so unless
> someone objects cogently, soon.

I see you already did, and on the emacs-26 branch.  Please in the
future ask about commits to the release branch.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Eric Abrahamsen-2
Eli Zaretskii <[hidden email]> writes:

>> From: Eric Abrahamsen <[hidden email]>
>> Date: Wed, 10 Oct 2018 16:05:50 -0700
>> Cc: [hidden email]
>>
>> I don't see any reason not to remove the `cdr', and will do so unless
>> someone objects cogently, soon.
>
> I see you already did, and on the emacs-26 branch.  Please in the
> future ask about commits to the release branch.
>
> Thanks.

Sorry about that -- it occurred to me I should have asked right after I
pushed. Will ask in the future.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Michael Heerdegen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

> I see you already did, and on the emacs-26 branch.  Please in the
> future ask about commits to the release branch.

Some days ago I asked a question about the habits and expectations
regarding bug fixes, in particular for bugs that were not introduced by
the current release.  Nobody disagreed that committing to the release is
just ok.  So it is not?  Why do you think people know what you expect?
(This is not a rant, I really just want to know what the rules and
expectations are.)


Michael.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Michael Heerdegen
In reply to this post by Eric Abrahamsen-2
Eric Abrahamsen <[hidden email]> writes:

> > Should we even make a NEWS entry along the fix saying that the feature
> > can actually be used now?
>
> I don't think so, bug fixes don't usually get a NEWS entry.

Well, it's at least the first time that you can actually use it.

> But I can say something on the gnus.general list.

Ok.

> Also, I really like the idea of using the registry to attach notes to
> mails -- that's something I've intended for Gnorb for a while. If you'd
> like to contribute that to Gnorb I'd be very happy to accept it, or
> maybe it's something that could even go into the registry proper. Of
> course, if you'd prefer to keep it a separate package that's fine too --
> I'd install it!

I wanted something really really simple, in particular, something that
is not linked to org.  It's an approach different from Gnorb, but maybe
it would fit into Gnus, dunno.  I attach what I have so far - feedback
welcome.


Michael.



gnus-article-notes.el (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Eric Abrahamsen-2

On 10/11/18 22:28 PM, Michael Heerdegen wrote:

[...]

> I wanted something really really simple, in particular, something that
> is not linked to org. It's an approach different from Gnorb, but maybe
> it would fit into Gnus, dunno. I attach what I have so far - feedback
> welcome.

Ha, I see what you mean, most of the code is for displaying and editing
the notes. I did something similar in org-annotate[1] (which is pretty
similar in spirit to what you're doing here, but for org files), but
just realized that I don't use the popup for editing, only display.

Well, let's see if anyone is interested in a generalized solution!

BTW I just used `set-local-key' in my function -- I don't think it's
necessary to make a new local keymap for a single-use buffer.

Eric

[1]: https://github.com/girzel/org-annotate/blob/master/org-annotate.el#L150


>
> Michael.
>
>
>;;; gnus-article-notes.el---Attach notes to messages in Gnus -*- lexical-binding: t -*-
>
>;; Copyright (C) 2018 Free Software Foundation, Inc
>
>;; Author: Michael Heerdegen <[hidden email]>
>;; Maintainer: Michael Heerdegen <[hidden email]>
>;; Created: 2017_12_11
>;; Keywords: news registry
>;; Version: 0.1
>;; Package-Requires: ()
>
>
>;; This file is not part of GNU Emacs.
>
>;; GNU Emacs is free software: you can redistribute it and/or modify
>;; it under the terms of the GNU General Public License as published by
> ;; the Free Software Foundation, either version 3 of the License, or
> ;; (at your option) any later version.
>
> ;; GNU Emacs is distributed in the hope that it will be useful,
> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ;; GNU General Public License for more details.
>
> ;; You should have received a copy of the GNU General Public License
> ;; along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
>
>
> ;;; Commentary:
>
> ;; This simple package allows to attach text notes to articles in
> ;; Gnus.  This is actually just a trivial convenience wrapper around
> ;; `gnus-registry-set-id-key' and `gnus-registry-get-id-key'.
> ;;
> ;; For something less simplistic see the Gnorb package in Gnu Elpa.
> ;; It can save notes in org files, track discussions, and much more.
> ;;
> ;;
> ;; Usage
> ;; =====
> ;;
> ;; The main command is `gnus-article-notes-set-note' bound to "@" in
> ;; the summary keymap.
> ;;
> ;; If the current article has not yet an attached note, hit @ to add
> ;; one.  The article is also flagged with an "@" to indicate that a
> ;; note has been attached.
> ;;
> ;; When an article has already an attached note, "@" displays the note
> ;; in the echo area, and hitting "@" again let's you edit the note.
> ;; "@" with a prefix argument 0 deletes the note after confirmation.
> ;; "@" with any other prefix arg also reads in a note text but using a
> ;; pop-up buffer instead of the minibuffer making editing multi-line
> ;; notes more convenient.
> ;;
> ;;
> ;; Setup
> ;; =====
> ;;
> ;; Somewhere in your initialization you need to enable the Gnus
> ;; registry (where this package saves your notes), load this file, and
> ;; make the key binding:
> ;;
> ;;   (gnus-registry-initialize)
> ;;   (require 'gnus-article-notes)
> ;;   (add-hook
> ;;    'gnus-summary-mode-hook
> ;;    (defun my-gnus-summary-mode-hook-bind-key-for-article-notes ()
> ;;      (define-key gnus-summary-mode-map [?@] #'gnus-article-notes-set-note)))
> ;;
> ;; It is a good idea to read about what enabling the registry means if
> ;; you haven't yet used it: (info "(gnus) The Gnus Registry").  It is
> ;; easy stuff.  You may want to limit how much data Gnus stores in the
> ;; registry to avoid delays when saving (it stores a lot by default).
> ;; I do (setq gnus-registry-max-entries 2000).  Note that pruning a
> ;; full registry will never delete notes unless you change
> ;; `gnus-registry-extra-entries-precious' to not contain `mark'.
> ;; Loading this package adds a "Note" named custom mark to
> ;; `gnus-registry-marks' (by default).
> ;;
> ;; To see the "@" marker for messages with attached notes in the
> ;; summary buffer, you also want something like
> ;;
> ;;   (defalias 'gnus-user-format-function-M
> ;;             'gnus-registry-article-marks-to-chars)
> ;;
> ;; which allows you to use "%uM" (or better with a padding like in
> ;; "%2uM") in `gnus-summary-line-format' to show registry marks - see
> ;; (info "(gnus) Store custom flags and keywords") for details.
> ;;
> ;; Finally you may also want to look at the few customizable options
> ;; defined in this file.
>
>
>
> ;;; Code:
>
>
>
> (eval-when-compile (require 'subr-x))
> (require 'gnus)
> (require 'gnus-registry)
>
> (defvar gnus-article-notes-registry-field 'Note)
> (defvar gnus-article-notes-marker-char ?@)
> (defvar gnus-article-notes-auto-tick nil)
>
> (defvar gnus-article-notes-show-in-summary t)
>
> (defun gnus-article-notes-registry-delete-id-key (id key)
>   (let* ((db gnus-registry-db)
>          (entry (gnus-registry-get-or-make-entry id)))
>     (registry-delete db (list id) nil)
>     (setq entry (assq-delete-all key entry))
>     (gnus-registry-insert db id entry)
>     entry))
>
> (with-eval-after-load 'gnus-registry
>   (add-to-list 'gnus-registry-marks
>                `(,gnus-article-notes-registry-field :char ,gnus-article-notes-marker-char :image nil)))
>
> (defvar gnus-article-notes-popup-window-action '())
>
> ;; We could make the major mode customizable...
> (defun gnus-article-notes-read-string-with-buffer (&optional initial-input keymap comment)
>   (cl-callf or comment ";; Hit C-c C-c when done\n\n") ;FIXME: add key to abort
>   (save-window-excursion
>     (with-temp-buffer
>       (let ((win (display-buffer (current-buffer) gnus-article-notes-popup-window-action)))
>         (select-window win)
>         (insert comment)
>         (when initial-input (insert initial-input))
>         (set-window-point win (point-max))
>         (use-local-map (let ((map (make-sparse-keymap)))
>                          (set-keymap-parent map (or keymap text-mode-map))
>                          (define-key map [(control ?c) (control ?c)] #'exit-recursive-edit)
>                          map))
>         (recursive-edit)
>         (string-trim
>          (replace-regexp-in-string
>           (concat "\\`" (regexp-quote comment)) ""
>           (buffer-string)))))))
>
> (defun gnus-article-notes-set-note (id new-content)
>   (if (not new-content)
>       (gnus-article-notes-registry-delete-id-key id gnus-article-notes-registry-field)
>     (gnus-registry-set-id-key id gnus-article-notes-registry-field new-content)))
>
> (defun gnus-article-notes-display-or-set-note (article id &optional content)
>   "Doc..."
>   (interactive
>    (let* ((articles (gnus-summary-work-articles nil))
>           (article (if (cdr articles) (user-error "Cannot operate on multiple articles")
>                      (car articles)))
>           (id (mail-header-id (gnus-summary-article-header article)))
>           (current-content (gnus-registry-get-id-key id gnus-article-notes-registry-field)))
>      (list article
>            id
>            (if (or (eq this-command last-command) (not current-content) current-prefix-arg)
>                (let ((new-content
>                       (if current-prefix-arg
>                           (if (eq 0 (prefix-numeric-value current-prefix-arg))
>                               (if (yes-or-no-p "Really delete note? ")
>                                   nil
>                                 (user-error "Abort"))
>                             (gnus-article-notes-read-string-with-buffer current-content))
>                         (read-string "New note: " current-content))))
>                  (if (equal "" new-content) nil new-content))
>              `(display . ,current-content)))))
>   (pcase content
>     (`(display . ,content) (message "%s" content))
>     (_ (when (and content gnus-article-notes-auto-tick) (gnus-summary-tick-article-forward 1))
>        (gnus-article-notes-set-note id content)
>        (gnus-registry--set/remove-mark 'Note (not content) (list article)))))
>
> (defun gnus-article-notes-get-additional-articles (group-name)
>   (delq nil
>         (mapcar (lambda (id) (cdr (gnus-request-head id group-name)))
>                 (cl-loop for key being the hash-keys of (oref gnus-registry-db data)
>                          using (hash-values v)
>                          when (assoc gnus-article-notes-registry-field v)
>                          collect key))))
>
>
> (defun gnus-articles-notes-alter-articles-to-read-function (f group-name article-list)
>   (let ((others (funcall f group-name article-list)))
>     (if gnus-article-notes-show-in-summary
>         (cl-union (gnus-article-notes-get-additional-articles group-name)
>                   others)
>       others)))
>
> (add-function :around gnus-alter-articles-to-read-function
>               #'gnus-articles-notes-alter-articles-to-read-function)
>
>
>
> (provide 'gnus-article-notes)
> ;;; gnus-article-notes.el ends here



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Michael Heerdegen
Eric Abrahamsen <[hidden email]> writes:

> BTW I just used `set-local-key' in my function -- I don't think it's
> necessary to make a new local keymap for a single-use buffer.

Don't know that function - do you mean `local-set-key'?  In this case I
must warn, citing the docstring of `local-set-key':

| The binding goes in the current buffer's local map, which in most
| cases is shared with all other buffers in the same major mode.


Michael.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Eric Abrahamsen-2
In reply to this post by Michael Heerdegen
Michael Heerdegen <[hidden email]> writes:

> Eric Abrahamsen <[hidden email]> writes:
>
>> BTW I just used `set-local-key' in my function -- I don't think it's
>> necessary to make a new local keymap for a single-use buffer.
>
> Don't know that function - do you mean `local-set-key'?  In this case I
> must warn, citing the docstring of `local-set-key':
>
> | The binding goes in the current buffer's local map, which in most
> | cases is shared with all other buffers in the same major mode.

I did mean `local-set-key' and did not realize that's how it works!
Thanks for the tip.

Eric




Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Eli Zaretskii
In reply to this post by Michael Heerdegen
> From: Michael Heerdegen <[hidden email]>
> Cc: Eric Abrahamsen <[hidden email]>,  [hidden email]
> Date: Thu, 11 Oct 2018 22:08:08 +0200
>
> Eli Zaretskii <[hidden email]> writes:
>
> > I see you already did, and on the emacs-26 branch.  Please in the
> > future ask about commits to the release branch.
>
> Some days ago I asked a question about the habits and expectations
> regarding bug fixes, in particular for bugs that were not introduced by
> the current release.  Nobody disagreed that committing to the release is
> just ok.  So it is not?

In general, it is.  But a bug fix should be safe enough to be eligible
for the release branch, and the "enough" part changes depending on the
state of the branch.  Currently, since Emacs 26.1 was already
released, only very safe fixes are eligible, and I'd like to be part
of the decision loop regarding the safety of each proposed fix.

> Why do you think people know what you expect?

Because I said it many times here.  The fact is, most people do ask.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Michael Heerdegen
Eli Zaretskii <[hidden email]> writes:

> > Why do you think people know what you expect?
>
> Because I said it many times here.  The fact is, most people do ask.

But CONTRIBUTE tells something different.  I have the feeling that some
people ask because they are lost, not because they know that it is
expected that they ask.  Others just don't ask.

Anyway, if it works for you...but I think it would be better to have
some rules written down somewhere if we want to be attractive to new
contributors.


Michael.



Reply | Threaded
Open this post in threaded view
|

bug#33005: 27.0.50; Data loss with Gnus registry

Eli Zaretskii
> From: Michael Heerdegen <[hidden email]>
> Cc: [hidden email],  [hidden email]
> Date: Fri, 12 Oct 2018 13:04:53 +0200
>
> Eli Zaretskii <[hidden email]> writes:
>
> > > Why do you think people know what you expect?
> >
> > Because I said it many times here.  The fact is, most people do ask.
>
> But CONTRIBUTE tells something different.

CONTRIBUTE's main audience is people who have no write access to the
Emacs repository, so what it says just tells them on what branch to
base the patches.  The decision to which branch to push is then made
by someone who actually pushes the changes.

I'm okay with adding the request to ask about committing to the
release branch, but at the time I was under the impression that some
people didn't agree with such a policy, so I'm not sure the project as
a whole would like it carved in stone from here to eternity.

> I have the feeling that some people ask because they are lost, not
> because they know that it is expected that they ask.

That's not the reality.  People explicitly ask _me_ whether it's okay
to push to the release branch; the exceptions are almost non-existent.



12