bug#39200: Release 27.1

bug#39200: Release 27.1

[Stefan Kangas]

help-debbugs@gnu.org (GNU bug Tracking System) writes:

> Thank you for filing a new bug report with debbugs.gnu.org.

Seems like there are two blocking bugs here that were marked as blocking
release 27.1:

41423: 27.0.91; eshell file completion in tramp dir is slow (3 minutes)
[regression on pretest]

36006: electric-pair-mode fails to balance in certain cases

It doesn't seem ideal that we missed these outstanding and presumably
release critical bugs.  Maybe someone should clean this up, and think
about how we should use bugs like this in the future.

Best regards,
Stefan Kangas

bug#39200: Release 27.1

[Michael Albinus]

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

>> Thank you for filing a new bug report with debbugs.gnu.org.
>
> Seems like there are two blocking bugs here that were marked as blocking
> release 27.1:
>
> 41423: 27.0.91; eshell file completion in tramp dir is slow (3 minutes)
> [regression on pretest]
>
> 36006: electric-pair-mode fails to balance in certain cases
>
> It doesn't seem ideal that we missed these outstanding and presumably
> release critical bugs.  Maybe someone should clean this up, and think
> about how we should use bugs like this in the future.

We still have no established and accepted method how to keep
must-to-be-fixed bugs. In fact, it depends mainly on the Emacs
maintainer(s) what to apply.

> Best regards,
> Stefan Kangas

Best regards, Michael.

bug#39200: Release 27.1

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 23 Aug 2020 09:26:12 -0400
> Cc: 39200@debbugs.gnu.org
> 
> Seems like there are two blocking bugs here that were marked as blocking
> release 27.1:
> 
> 41423: 27.0.91; eshell file completion in tramp dir is slow (3 minutes)
> [regression on pretest]
> 
> 36006: electric-pair-mode fails to balance in certain cases
> 
> It doesn't seem ideal that we missed these outstanding and presumably
> release critical bugs.

We didn't miss them.  I decided they weren't important enough to hold
the release.

bug#39200: Release 27.1

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Seems like there are two blocking bugs here that were marked as blocking
>> release 27.1:
>>
>> 41423: 27.0.91; eshell file completion in tramp dir is slow (3 minutes)
>> [regression on pretest]
>>
>> 36006: electric-pair-mode fails to balance in certain cases
>>
>> It doesn't seem ideal that we missed these outstanding and presumably
>> release critical bugs.
>
> We didn't miss them.  I decided they weren't important enough to hold
> the release.

That's pretty OK as maintainer decision. But shouldn't the two bugs then
be removed from blocking ones for bug#39200? At least a communication
about this decision I have missed, perhaps because I didn't see it.

And should the two bugs now be marked as blocking for 27.2.?

(Sorry to bother you, but I feel like at home: my wife also expects from
me to read her mind and to do proper action, but I fail miserably)

Best regards, Michael.

bug#39200: Release 27.1

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Stefan Kangas <stefan@marxist.se>,  39200@debbugs.gnu.org
> Date: Sun, 23 Aug 2020 20:57:42 +0200
> 
> > We didn't miss them.  I decided they weren't important enough to hold
> > the release.
> 
> That's pretty OK as maintainer decision. But shouldn't the two bugs then
> be removed from blocking ones for bug#39200? At least a communication
> about this decision I have missed, perhaps because I didn't see it.

Some people react emotionally when I close bugs against their
opinions, so I sometimes decide not to do that.

> And should the two bugs now be marked as blocking for 27.2.?

I don't mind, but if the motivation for fixing them will remain as it
was until now, they will probably be ignored for 27.2 as well.  it is
hard to treat seriously a bug report that no one feels motivated
enough to work on.

bug#39200: Release 27.1

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> We didn't miss them.  I decided they weren't important enough to hold
> the release.

OK, sounds good, and thanks for clarifying.

I've now renamed this bug to "Release 27.2".  I hope that makes sense
and is somehow helpful for you in preparing the next release.

Perhaps some other adjustments should be made here; some of the blocking
bugs might not be important enough to block 27.2 either, for example.

Best regards,
Stefan Kangas

bug#39200: Release 27.1

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> And should the two bugs now be marked as blocking for 27.2.?
>
> I don't mind, but if the motivation for fixing them will remain as it
> was until now, they will probably be ignored for 27.2 as well.  it is
> hard to treat seriously a bug report that no one feels motivated
> enough to work on.

Agreed.

OTOH, it wasn't propagated prominently, that there is a list of
to-be-solved-for-relase bugs. Not so many people know how to see this
list. And maybe we shall send (weekly?) reminder messages with these bug
ids to the emacs-devel ML. WDYT?

Best regards, Michael-

bug#39200: Release 27.1

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: stefan@marxist.se,  39200@debbugs.gnu.org
> Date: Sun, 23 Aug 2020 21:10:21 +0200
> 
> OTOH, it wasn't propagated prominently, that there is a list of
> to-be-solved-for-relase bugs. Not so many people know how to see this
> list. And maybe we shall send (weekly?) reminder messages with these bug
> ids to the emacs-devel ML. WDYT?

I don't mind, although weekly sounds too frequently.

bug#39200: Release 27.1

[Michael Albinus]

Stefan Kangas <stefan@marxist.se> writes:

> I've now renamed this bug to "Release 27.2".  I hope that makes sense
> and is somehow helpful for you in preparing the next release.

No, pls revert this renaming. I will create a new bug for 27.2, and I
will update the debbugs package. Likely by tomorrow. (If you beat me -
the better)

If we don't distinguish between releases, there are good chances people
get confused.

> Perhaps some other adjustments should be made here; some of the blocking
> bugs might not be important enough to block 27.2 either, for example.

Yes, perhaps. Unfortunately, nobody feels even responsible to keep this
list of blocking bugs up-to-date.

> Best regards,
> Stefan Kangas

Best regards, Michael.

bug#39200: Release 27.1

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> OTOH, it wasn't propagated prominently, that there is a list of
>> to-be-solved-for-relase bugs. Not so many people know how to see this
>> list. And maybe we shall send (weekly?) reminder messages with these bug
>> ids to the emacs-devel ML. WDYT?
>
> I don't mind, although weekly sounds too frequently.

Let's say monthly, and weekly once the pretest has started?

I could add a script to the debbugs package, which will do the dirty
steps collecting data and preparing the message. Activation shall still
be performed manually, by whomever feels ready.

Best regards, Michael.

bug#39200: Release 27.1

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: stefan@marxist.se,  39200@debbugs.gnu.org
> Date: Sun, 23 Aug 2020 21:23:37 +0200
> 
> Let's say monthly, and weekly once the pretest has started?
> 
> I could add a script to the debbugs package, which will do the dirty
> steps collecting data and preparing the message. Activation shall still
> be performed manually, by whomever feels ready.

Fine with me, thanks.

bug#39200: Release 27.1

[Stefan Kangas]

retitle 39200 Release 27.1
thanks

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

>> I've now renamed this bug to "Release 27.2".
>
> No, pls revert this renaming.
[...]
> If we don't distinguish between releases, there are good chances people
> get confused.

Good point, done.

Best regards,
Stefan Kangas

bug#39200: Release 27.1

[Dmitry Gutov]

On 23.08.2020 22:01, Eli Zaretskii wrote:
>>> We didn't miss them.  I decided they weren't important enough to hold
>>> the release.
>> That's pretty OK as maintainer decision. But shouldn't the two bugs then
>> be removed from blocking ones for bug#39200? At least a communication
>> about this decision I have missed, perhaps because I didn't see it.
> Some people react emotionally when I close bugs against their
> opinions, so I sometimes decide not to do that.

I believe the suggestion was to remove them from blockers, not closing 
them. If anyone objects to that, they would object to making a release 
before the bugs as fixed as well.

bug#39200: Release 27.1

[Noam Postavsky]

Stefan Kangas <stefan@marxist.se> writes:

> 36006: electric-pair-mode fails to balance in certain cases
>
> It doesn't seem ideal that we missed these outstanding and presumably
> release critical bugs.  Maybe someone should clean this up, and think
> about how we should use bugs like this in the future.

I added 36006 as a blocker because it's a regression, but I wouldn't
call it release critical.  I did intend to look at it before release,
but I haven't spent much time on Emacs development recently, for various
reasons.

bug#39200: Release 27.1

[Eli Zaretskii]

> Cc: stefan@marxist.se, 39200@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 24 Aug 2020 01:58:21 +0300
> 
> On 23.08.2020 22:01, Eli Zaretskii wrote:
> >>> We didn't miss them.  I decided they weren't important enough to hold
> >>> the release.
> >> That's pretty OK as maintainer decision. But shouldn't the two bugs then
> >> be removed from blocking ones for bug#39200? At least a communication
> >> about this decision I have missed, perhaps because I didn't see it.
> > Some people react emotionally when I close bugs against their
> > opinions, so I sometimes decide not to do that.
> 
> I believe the suggestion was to remove them from blockers, not closing 
> them.

Same issue here.

bug#39200: Release 27.1

[Michael Albinus]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> I could add a script to the debbugs package, which will do the dirty
>> steps collecting data and preparing the message. Activation shall still
>> be performed manually, by whomever feels ready.
>
> Fine with me, thanks.

Finally, I've added the command `reminder-for-release-critical-bugs' to
admin/admin.el of the emacs-27 branch. See appended patch.

Comments, especially about the wording of the message, are welcome.

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2754 bytes --]

*** /tmp/ediffR9vehu	2020-08-24 18:00:11.883133992 +0200
--- /home/albinus/src/emacs-27/admin/admin.el	2020-08-24 17:56:38.271440689 +0200
***************
*** 921,926 ****
--- 921,978 ----
  			      'help-echo "Mouse-2: visit this definition"
  			      :type 'cusver-xref)))))))

+ \f
+ ;; Reminder message for open release-critical bugs.  This requires the
+ ;; GNU ELPA package `debbugs'.
+
+ (defun reminder-for-release-critical-bugs (version)
+   "Submit a reminder message for release critical bugs of Emacs VERSION."
+   (interactive
+    (list (read-string "Version number: "
+                       (pcase (nbutlast (version-to-list emacs-version)
+                                        ;; Chop off build number, if needed.
+                                        (if (boundp 'emacs-build-number)
+                                            0 1))
+                         (`(,major ,minor ,_micro) ; Development version.
+                          (format "%d.%d" major (1+ minor)))
+                         (`(,major ,minor)    ; Release version.
+                          (format "%d.%d" major minor))
+                         ;; Unexpected version format?
+                         (_ emacs-version)))))
+
+   (require 'reporter)
+   (require 'debbugs-gnu)
+
+   (when-let ((id (alist-get version debbugs-gnu-emacs-blocking-reports
+                             nil nil #'string-equal))
+              (status-id (debbugs-get-status id))
+              (blockedby-ids (debbugs-get-attribute (car status-id) 'blockedby))
+              (blockedby-status
+               (apply #'debbugs-get-status (sort blockedby-ids #'<))))
+
+     (reporter-submit-bug-report
+      "<emacs-devel@gnu.org>" ; to-address
+      nil nil nil
+      (lambda () ; posthook
+        (goto-char (point-min))
+        (mail-position-on-field "subject")
+        (insert (format "Release-critical bugs for Emacs %s" version))
+        (mail-text)
+        (delete-region (point) (point-max))
+        (insert "
+ The following bugs are regarded as release-critical for Emacs " version ".
+ People are encouraged to work on them with priority.\n\n")
+        (dolist (_ blockedby-status)
+          (unless (equal (debbugs-get-attribute _ 'pending) "done")
+            (insert (format "bug#%d %s\n"
+                            (debbugs-get-attribute _ 'id)
+                            (debbugs-get-attribute _ 'subject)))))
+        (insert "
+ If you use the debbugs package from GNU ELPA, you can apply the
+ following form to see all bugs which block a given release:
+
+   (debbugs-gnu-emacs-release-blocking-reports \"" version "\")\n")))))
+
  (provide 'admin)

  ;;; admin.el ends here

bug#39200: Release 27.1

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: stefan@marxist.se,  39200@debbugs.gnu.org
> Date: Mon, 24 Aug 2020 18:05:53 +0200
> 
> Finally, I've added the command `reminder-for-release-critical-bugs' to
> admin/admin.el of the emacs-27 branch. See appended patch.
> 
> Comments, especially about the wording of the message, are welcome.

I think someone already said those are not necessarily "critical".
How about "release-blocking" instead?

bug#39200: Release 27.1

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Finally, I've added the command `reminder-for-release-critical-bugs' to
>> admin/admin.el of the emacs-27 branch. See appended patch.
>>
>> Comments, especially about the wording of the message, are welcome.
>
> I think someone already said those are not necessarily "critical".
> How about "release-blocking" instead?

I'll change.

Best regards, Michael.