Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[John Wiegley]

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

[I'm moving this discussion from Bug #23288 to Emacs-Devel, to widen
participation]

>>>>> Glenn Morris <rgm@gnu.org> writes:

> Eli Zaretskii wrote:
>> Sorry, I don't see the list of blocking bugs being treated seriously. If we
>> did treat it seriously, we wouldn't have had "deep freeze" on emacs-25, and
>> wouldn't be planning the release in less than a month.

> Indeed. Though I have noticed some people looking at those issues recently
> (thanks!).

> I'd hope those in charge would be encouraging people to work on those
> issues, but I haven't noticed it happening.

I've already asked for everyone to focus on that list until release. Did you
not see that? I've mentioned it in a few places.

> Previous Emacs releases weren't time-based, but were made when they were
> ready.

I only introduced a date to focus our decision making around 25.1, and since
this is what I'm used to doing to ship software.

HOWEVER, if having a date is stressful or unpleasant for those doing the work,
we can get rid of it. I'm not doing this to put undue pressure on anyone.
Personally, I don't mind if Emacs 25 takes another year to happen, since the
pretests are working well and 24.5 is fully capable.

I want to know what works best for those doing the actual release work. Do you
want a timeframe? Do you want a release-blocking list?

If you'd prefer to do this in an unstructured way -- if that's what will
improve our bug closure rate and our code quality -- then by all means. But I
want to hear that from the core developers first, as it also introduces a bit
of chaos (for example, I'd have no real metric by which to ask people to
revert a change they just made on a release branch, other than gut feeling).

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

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

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Paul Eggert]

On 05/12/2016 10:21 AM, John Wiegley wrote:
> I only introduced a date to focus our decision making around 25.1, and 
> since
> this is what I'm used to doing to ship software.
>
> HOWEVER, if having a date is stressful or unpleasant for those doing the work,
> we can get rid of it.

The date is arbitrary and should not be driving development. That being 
said, the list of blocking bugs is too long: currently 28 entries, and 
they are largely nontrivial. The list needs to be whittled down.

> I don't mind if Emacs 25 takes another year to happen

I would mind. Two years between releases is too long. This isn't gzip 
we're talking about.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Glenn Morris]

"Blocking" is just the debbugs terminology. When I add something to
this list, it is something I think needs "attention" before the
release. (I tend to throw any obvious regression wrt to 24 on there.)
"Attention" can mean someone taking 30 seconds to make an informed
comment "this isn't an issue for 25.1 because X". (In which case they
may want to shift it to #21966.)

I'd hope it would go without saying, but feel free to remove things
If I disagree, I'll comment in the relevant report.

(BTW, I've never claimed my additions are exhaustive.)

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[John Wiegley]

>>>>> Glenn Morris <rgm@gnu.org> writes:

> "Blocking" is just the debbugs terminology. When I add something to this
> list, it is something I think needs "attention" before the release. (I tend
> to throw any obvious regression wrt to 24 on there.) "Attention" can mean
> someone taking 30 seconds to make an informed comment "this isn't an issue
> for 25.1 because X". (In which case they may want to shift it to #21966.)

> I'd hope it would go without saying, but feel free to remove things If I
> disagree, I'll comment in the relevant report.

Then by all means, let's please unblock all the bugs we can, so that we have a
real list of pressing issues to look at.  Eli, if they don't look serious to
you, just unblock them, and we'll let others comment if they disagree after.

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

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  Eli Zaretskii <eliz@gnu.org>,  p.stephani2@gmail.com,  nilsb@google.com,  emacs-devel <emacs-devel@gnu.org>
> Date: Tue, 17 May 2016 23:09:08 -0700
> 
> >>>>> Glenn Morris <rgm@gnu.org> writes:
> 
> > "Blocking" is just the debbugs terminology. When I add something to this
> > list, it is something I think needs "attention" before the release. (I tend
> > to throw any obvious regression wrt to 24 on there.) "Attention" can mean
> > someone taking 30 seconds to make an informed comment "this isn't an issue
> > for 25.1 because X". (In which case they may want to shift it to #21966.)
> 
> > I'd hope it would go without saying, but feel free to remove things If I
> > disagree, I'll comment in the relevant report.
> 
> Then by all means, let's please unblock all the bugs we can, so that we have a
> real list of pressing issues to look at.  Eli, if they don't look serious to
> you, just unblock them, and we'll let others comment if they disagree after.

Thanks to efforts by Paul and others, the current list is just this:

17693  24.3.91.1; desktop-save-mode disables option -nw
17976  24.3; url-retrieve-synchronously doesn't fallback to IPv4
19548  VC changes under-documented, needlessly incompatible
19717  24.4.50; printing.el still uses ps-eval-switch
20247  24.4; Emacs hangs at startup in desktop mode
21182  25.0.50; gnus: every other unread message is marked as read on
21650  24.5; mh-e keeps trying to open urls
21871  Emacs Lisp Mode (at least): spurious parens in column 0 don't get
21874  25.0.50; point-entered no longer works
22107  this-command-keys no longer returns prefix argument
22147  Obsolete search-forward-lax-whitespace
22295  viper-mode undo bug introduced between Nov 10 and Nov 14
22338  25.0.50; deactivate-mark regression
22434  25.0.50; recentf pastes X clipboard upon opening
22795  25.0.91; Can't write read only file on w32
23050  package.el overwrites symlinks when saving "(package-initialize)"
23360  bug fonts display overlap all versions
23519  25.0.93; pasting with the middle mouse button while searching

Here's my suggestions for how to treat these:

  17693 -- patch was proposed, suggest to push and close the bug
  17976 -- missing feature, shouldn't be blocking
  19548 -- not clear what should be done there; shouldn't block
  19717 -- patch was proposed, suggest to push and close
  20247 -- for Emacs 25.1, suggest to default
           desktop-restore-in-current-display to t, and then release the block
  21182 -- not serious enough to block the release
  21650 -- AFAIU is now a n MH-E issue, so shouldn't block the release
  21871 -- not serious enough to block the release
  21874 -- looks like a minor issue to me, certainly not worthy of blocking
  22107 -- less than a minor issue, given the behavior is perceived correct
  22147 -- not serious enough to block the release
  22295 -- solution exists on a branch; suggest to merge it and close
  22338 -- minor issue that happens in rare situations; shouldn't block
  22434 -- sounds serious; could someone please work on this one?
  22795 -- I'm waiting for the OP to present more info
  23050 -- Glenn suggested a solution, I suggest to accept it
  23360 -- I will add a variable to allow to work around the problem
  23519 -- a solution was proposed, so we can solve this

If no one objects, 6 bugs can be solved and closed, 9 should be
removed from the blocking list, 2 I will solve, and 1 (22434) awaits
someone to work and fix.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Mike Kupfer]

Eli Zaretskii wrote:

>   21650 -- AFAIU is now a n MH-E issue, so shouldn't block the release

Agreed, no longer a blocker.  All the the necessary code changes are
already in the emacs-25 branch.

The only remaining work that I'm aware of for this bug is updating the
MH-E documentation to mention the new controls that Katsumi kindly
implemented.  (Bill, are you going to have time to apply the patch I
submitted?)

mike

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Bill Wohler]

Soon. Sorry, I was releasing software, flying on SOFIA, and moving. I
know. No excuse. Unlike jury duty, which I was excused from recently.

We have a three-day weekend next week, so I am hopeful.

Mike Kupfer <m.kupfer@acm.org> wrote:

> Eli Zaretskii wrote:
> 
> >   21650 -- AFAIU is now a n MH-E issue, so shouldn't block the release
> 
> Agreed, no longer a blocker.  All the the necessary code changes are
> already in the emacs-25 branch.
> 
> The only remaining work that I'm aware of for this bug is updating the
> MH-E documentation to mention the new controls that Katsumi kindly
> implemented.  (Bill, are you going to have time to apply the patch I
> submitted?)
> 
> mike

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Bill Wohler]

Mike Kupfer <m.kupfer@acm.org> wrote:

> Eli Zaretskii wrote:
> 
> >   21650 -- AFAIU is now a n MH-E issue, so shouldn't block the release
> 
> Agreed, no longer a blocker.  All the the necessary code changes are
> already in the emacs-25 branch.
> 
> The only remaining work that I'm aware of for this bug is updating the
> MH-E documentation to mention the new controls that Katsumi kindly
> implemented.  (Bill, are you going to have time to apply the patch I
> submitted?)

I just pushed the change to the emacs-25 branch.

> mike

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Paul Eggert]

Eli Zaretskii wrote:
>    20247 -- for Emacs 25.1, suggest to default
>             desktop-restore-in-current-display to t, and then release the block

Yes, that's my thought too; see <http://bugs.gnu.org/20247#16>. This is a change 
to Emacs behavior and I said I'd mention this on emacs-devel before installing 
it, but now I see you beat me to mentioning it.

The main objections in that bug report to changing the default were along the 
lines of "someone should come up with a better fix", which of course would be 
nice if someone had the time to do that. In the meantime changing the default 
would have prevented the reported problem and seems like an improvement overall.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[John Wiegley]

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

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

> If no one objects, 6 bugs can be solved and closed, 9 should be removed from
> the blocking list, 2 I will solve, and 1 (22434) awaits someone to work and
> fix.

No objections from me.

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

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

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 21 May 2016 21:52:55 -0700
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If no one objects, 6 bugs can be solved and closed, 9 should be removed from
> > the blocking list, 2 I will solve, and 1 (22434) awaits someone to work and
> > fix.
> 
> No objections from me.

Thanks, I've removed from the blocking list all of the minor issues.
The rest are those for which solutions are available and await
pushing/merging, and a couple that are still being worked on.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Eli Zaretskii]

> Date: Sat, 21 May 2016 22:06:13 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>   23360 -- I will add a variable to allow to work around the problem

Done.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Dmitry Gutov]

On 05/21/2016 10:06 PM, Eli Zaretskii wrote:

>   19548 -- not clear what should be done there; shouldn't block

About this one: I've outlined the current situation with vc-stay-local, 
and I'm not sure whether it needs changing.

I think you and John should take a look.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Dmitry Gutov]

Does anyone object to adding bug#23508 to the blockers list?

 From the description, it seems like a regression from Emacs 24.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 23 May 2016 00:24:23 +0300
> 
> Does anyone object to adding bug#23508 to the blockers list?
> 
>  From the description, it seems like a regression from Emacs 24.

It's a regression, but AFAIU it only exists on master, so doesn't
affect Emacs 25.1.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Dmitry Gutov]

On 05/23/2016 05:32 AM, Eli Zaretskii wrote:

>> Does anyone object to adding bug#23508 to the blockers list?
>>
>>  From the description, it seems like a regression from Emacs 24.
>
> It's a regression, but AFAIU it only exists on master, so doesn't
> affect Emacs 25.1.

Oh, ok, sorry.

Could you look at bug#23595, then? It shows a behavior that became worse 
in 25.1 since 24.5 (even though it's not so great in 24.5 either).

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Paul Eggert]

On 05/23/2016 06:18 AM, Dmitry Gutov wrote:
> Could you look at bug#23595, then? It shows a behavior that became 
> worse in 25.1 since 24.5 (even though it's not so great in 24.5 either). 

I get the same awful behavior with both 24.5 and 25, at least when 
registering the file under RCS using Fedora 23. In both cases, Emacs 
displays mojibake because rcsdiff outputs a "Binary files ... differ" 
message in ASCII and Emacs I guess assumes that the message is in 
UTF-16. It's obviously a bug but I don't see a regression.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Dmitry Gutov]

On 05/23/2016 07:15 PM, Paul Eggert wrote:

> I get the same awful behavior with both 24.5 and 25, at least when
> registering the file under RCS using Fedora 23.

I don't see it with Git in 24.5. Just "Binary files a/test-chin-jap.tex 
and b/test-chin-jap.tex differ".

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Paul Eggert]

On 05/23/2016 09:36 AM, Dmitry Gutov wrote:
> I don't see it with Git in 24.5. Just "Binary files 
> a/test-chin-jap.tex and b/test-chin-jap.tex differ". 

Ah, I didn't test Git, only RCS. You're right, there is a regression for 
Git (which is way more important than RCS these days). I will follow up 
on Bug#23595. Whether this is a blocker depends on the importance of 
Git-controlled UTF-16 files.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Eli Zaretskii]

> Cc: jwiegley@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 23 May 2016 09:15:30 -0700
> 
> On 05/23/2016 06:18 AM, Dmitry Gutov wrote:
> > Could you look at bug#23595, then? It shows a behavior that became 
> > worse in 25.1 since 24.5 (even though it's not so great in 24.5 either). 
> 
> I get the same awful behavior with both 24.5 and 25, at least when 
> registering the file under RCS using Fedora 23. In both cases, Emacs 
> displays mojibake because rcsdiff outputs a "Binary files ... differ" 
> message in ASCII and Emacs I guess assumes that the message is in 
> UTF-16. It's obviously a bug but I don't see a regression.

Right, I agree.  Does "git diff --text" fix this?

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  p.stephani2@gmail.com,  emacs-devel <emacs-devel@gnu.org>, nilsb@google.com
> Date: Thu, 12 May 2016 10:21:55 -0700
> 
> I've already asked for everyone to focus on that list until release. Did you
> not see that? I've mentioned it in a few places.

That evidently doesn't help enough.

> > Previous Emacs releases weren't time-based, but were made when they were
> > ready.
> 
> I only introduced a date to focus our decision making around 25.1, and since
> this is what I'm used to doing to ship software.
> 
> HOWEVER, if having a date is stressful or unpleasant for those doing the work,
> we can get rid of it. I'm not doing this to put undue pressure on anyone.
> Personally, I don't mind if Emacs 25 takes another year to happen, since the
> pretests are working well and 24.5 is fully capable.

It's not stressful.  It's just strange, to say the least, to see a
long list of bugs designated as blocking, with the imminent release
date approaching fast, and almost no one investing any work of any
kind on the blocking bugs, be it re-classifying them so that the list
becomes shorter, or solving them.  Instead, almost everyone work on
master, as if the release is not important at all.

> I want to know what works best for those doing the actual release work. Do you
> want a timeframe? Do you want a release-blocking list?

FWIW, I'd like to see more people working on the bugs deemed blocking
the release.  For instance, some of the bugs identify the commit that
caused it, so the people who made those commits should hopefully step
forward and work on the issues.

Bottom line, there seems to be a certain dissonance between the
announced release date and how we invest our resources.  It's
confusing, at least from my POV.

Re: Making better use of the "release blocking list" [was: bug#23288: 25.0.92; Clicking on links inserts primary X selection]

[John Wiegley]

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

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

>> I want to know what works best for those doing the actual release work. Do
>> you want a timeframe? Do you want a release-blocking list?

> FWIW, I'd like to see more people working on the bugs deemed blocking the
> release. For instance, some of the bugs identify the commit that caused it,
> so the people who made those commits should hopefully step forward and work
> on the issues.

> Bottom line, there seems to be a certain dissonance between the announced
> release date and how we invest our resources. It's confusing, at least from
> my POV.

I couldn't agree more, Eli.

We're all volunteers, so I understand people are free to work on whatever
pleases them. But if those reading this are interested in the quality of our
next Emacs release, please dedicate your next several weeks to reducing the
blocking list to zero, even if that means just removing them from the list
after reviewing them.

Once we hit zero, and can stay at zero for at least several days, we will ship
and shift to 25.2/26.1 quickly after (there are already a few fixes queued up
for 25.2, as I understand; and development for 26.1 is currently underway).

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

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