Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Glenn Morris]

GNU bug tracker automated control server wrote:

> Processing commands for control@debbugs.gnu.org:
>
>> unblock 19759 by 23050

Again, this is not necessary. Closed bugs are not included in the list
at the top of http://debbugs.gnu.org/19759

Explicitly unblocking closed bugs is harmful, because if the bug needs
to be reopened for some reason, it won't reappear in the blocking list.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Emacs developers <emacs-devel@gnu.org>
> Date: Mon, 23 May 2016 11:40:48 -0400
> 
> GNU bug tracker automated control server wrote:
> 
> > Processing commands for control@debbugs.gnu.org:
> >
> >> unblock 19759 by 23050
> 
> Again, this is not necessary.

I remembered you said that, but the facts are otherwise, sorry.

> Closed bugs are not included in the list at the top of
> http://debbugs.gnu.org/19759

They are for me.  I do need glasses, but I still see very well, I
assure you.

> Explicitly unblocking closed bugs is harmful, because if the bug needs
> to be reopened for some reason, it won't reappear in the blocking list.

Sorry, I have no other way to display the list of blockers as it
really is.  Maybe it's a debbugs bug, I don't know.  But the problem
is real, and I did the only thing I know about that helps.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Paul Eggert]

On 05/23/2016 09:32 AM, Eli Zaretskii wrote:
>> >Closed bugs are not included in the list at the top of
>> >http://debbugs.gnu.org/19759
> They are for me.

What I've noticed, is that http://debbugs.gnu.org/19759 is often cached 
(whether in my browser or somewhere else, I haven't checked), and when I 
close a blocking bug the closed bug is still listed on that web page as 
a blocker, until I refresh the cache. This is independent of whether the 
bug is still listed as a blocker.

Glenn is right: it shouldn't be necessary to remove the bug as a 
blocking bug. If there is something other than caching that is causing 
this problem it'd be nice to know what it is.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 23 May 2016 09:44:44 -0700
> 
> On 05/23/2016 09:32 AM, Eli Zaretskii wrote:
> >> >Closed bugs are not included in the list at the top of
> >> >http://debbugs.gnu.org/19759
> > They are for me.
> 
> What I've noticed, is that http://debbugs.gnu.org/19759 is often cached 
> (whether in my browser or somewhere else, I haven't checked), and when I 
> close a blocking bug the closed bug is still listed on that web page as 
> a blocker, until I refresh the cache. This is independent of whether the 
> bug is still listed as a blocker.

IME, the bug is still listed as blocking long after it was closed, no
matter how many times I refresh the browser page.  But when I send the
control message to the tracker that unblocks it, the next refresh of
the browser updates the display by removing that bug.

So if some cache is involved in this, it reacts differently to closing
a bug and to removing it from the blockers list.

> Glenn is right: it shouldn't be necessary to remove the bug as a 
> blocking bug. If there is something other than caching that is causing 
> this problem it'd be nice to know what it is.

Hey, I tried, okay?  I didn't do it because I deliberately ignored
Glenn's requests.  I even told him in the past (off list) that what he
asks for didn't work for me.  I just don't want to let software
problems prevent me from doing my job.  If there's a bug there
somewhere that causes the phenomenon I described above, I'm all for
fixing it, and will be the first to avoid sending control messages
when it is fixed -- it's not like I enjoy writing those messages.

TIA

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Paul Eggert]

On 05/23/2016 10:00 AM, Eli Zaretskii wrote:
> IME, the bug is still listed as blocking long after it was closed, no
> matter how many times I refresh the browser page.  But when I send the
> control message to the tracker that unblocks it, the next refresh of
> the browser updates the display by removing that bug.

Weird, that's not my experience: if I close a blocking bug, wait for a 
bit (to make sure my bug-close email has hit the debbugs server), and 
hard-refresh <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759>, the 
blocking bug is no longer listed as a blocker.

I hard-refresh by using Firefox. I hold down the shift key, and press on 
the cycle icon at the right of the main URL.

Perhaps the next time you close a blocking bug B, you might try looking 
at B's page first and waiting until it's marked "done", and then try 
refreshing Bug#19759. If you still see B listed as blocking in 
Bug#19759, you might try using Firefox in the way that I described. This 
might help us get to the bottom of the problem here.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Eli Zaretskii]

> Cc: rgm@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 23 May 2016 10:32:08 -0700
> 
> On 05/23/2016 10:00 AM, Eli Zaretskii wrote:
> > IME, the bug is still listed as blocking long after it was closed, no
> > matter how many times I refresh the browser page.  But when I send the
> > control message to the tracker that unblocks it, the next refresh of
> > the browser updates the display by removing that bug.
> 
> Weird, that's not my experience: if I close a blocking bug, wait for a 
> bit (to make sure my bug-close email has hit the debbugs server), and 
> hard-refresh <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759>, the 
> blocking bug is no longer listed as a blocker.
> 
> I hard-refresh by using Firefox. I hold down the shift key, and press on 
> the cycle icon at the right of the main URL.

My point is that no such hard-refresh (about whose existence I didn't
even know) is needed when I send the control command to the tracker to
remove a big from the blocking list.

> Perhaps the next time you close a blocking bug B, you might try looking 
> at B's page first and waiting until it's marked "done", and then try 
> refreshing Bug#19759.

That's what I did.  The bug was "done", but refereshing the 19759 page
didn't remove it.  When I sent the control message, it was removed on
the next refresh a few minutes later.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[John Wiegley]

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

>> Perhaps the next time you close a blocking bug B, you might try looking at
>> B's page first and waiting until it's marked "done", and then try
>> refreshing Bug#19759.

> That's what I did. The bug was "done", but refereshing the 19759 page didn't
> remove it. When I sent the control message, it was removed on the next
> refresh a few minutes later.

Clearly we need something that doesn't require jumping through hoops, such as
a hard refresh (which I don't even know how to do outside of Firefox). If that
means unblocking bugs for now, then debbugs needs some improvement.

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

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[John Mastro]

John Wiegley <jwiegley@gmail.com> wrote:
> Clearly we need something that doesn't require jumping through hoops, such as
> a hard refresh (which I don't even know how to do outside of Firefox). If that
> means unblocking bugs for now, then debbugs needs some improvement.

FWIW, I believe [C-f5] will work for all the major browsers on both
GNU/Linux and Windows. (I think it's Command-Shift-r on OS X but I'm not
as sure.)

        John

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Eli Zaretskii]

> From: John Mastro <john.b.mastro@gmail.com>
> Date: Mon, 23 May 2016 11:39:48 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, Paul Eggert <eggert@cs.ucla.edu>, rgm@gnu.org
> 
> John Wiegley <jwiegley@gmail.com> wrote:
> > Clearly we need something that doesn't require jumping through hoops, such as
> > a hard refresh (which I don't even know how to do outside of Firefox). If that
> > means unblocking bugs for now, then debbugs needs some improvement.
> 
> FWIW, I believe [C-f5] will work for all the major browsers on both
> GNU/Linux and Windows. (I think it's Command-Shift-r on OS X but I'm not
> as sure.)

FWIW, I believe that no such gesture should be needed to begin with, a
simple refresh should do.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[John Wiegley]

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

> FWIW, I believe that no such gesture should be needed to begin with, a
> simple refresh should do.

I also agree; it's confusing to have to remember that special need for this
one project.

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

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Glenn Morris]

Please try to use standard ctrl-f5 or equivalent rather than unnecessary
unblock commands.

https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache

There won't be any changes to debbugs.gnu.org.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Kaushal Modi]

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

On Tue, May 24, 2016 at 11:38 AM Glenn Morris <rgm@gnu.org> wrote:

>
> Please try to use standard ctrl-f5 or equivalent rather than unnecessary
> unblock commands.
>
> https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache
>
> There won't be any changes to debbugs.gnu.org.
>

I agree, Ctrl-F5 has been my natural reflex when the browsers fetch stale
stuff from their cache. I've been using that on Chrome/Firefox for ever. As
you said, this has nothing to do with debbugs but with browser
technologies.
-- 

-- 
Kaushal Modi

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

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 24 May 2016 15:41:40 +0000
> 
>  Please try to use standard ctrl-f5 or equivalent rather than unnecessary
>  unblock commands.
> 
>  https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache
> 
>  There won't be any changes to debbugs.gnu.org.
> 
> I agree, Ctrl-F5 has been my natural reflex when the browsers fetch stale stuff from their cache. I've been
> using that on Chrome/Firefox for ever. As you said, this has nothing to do with debbugs but with browser
> technologies. 

As I've explained numerous times earlier, I have hard time believing
this is a browser issue, because just clicking on the "refresh" icon
immediately refreshes the list of blocking bugs after I send an
unblock command to debbugs.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Paul Eggert]

On 05/24/2016 08:59 AM, Eli Zaretskii wrote:
> I have hard time believing this is a browser issue

I don't. There are different kinds of refreshes, and it's possible that 
a partial refresh won't give you a new page at the same time that a full 
refresh would.

Anyway, this question should be resolvable easily the next time you fix 
a blocking bug, by trying out Firefox on the bug in question.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 24 May 2016 09:47:35 -0700
> Cc: rgm@gnu.org, emacs-devel@gnu.org
> 
> On 05/24/2016 08:59 AM, Eli Zaretskii wrote:
> > I have hard time believing this is a browser issue
> 
> I don't. There are different kinds of refreshes, and it's possible that 
> a partial refresh won't give you a new page at the same time that a full 
> refresh would.

That makes no sense at all.  It's the same browser and the same Web
page.  How can the browser know to refresh it in one case, but not in
the other?

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Chad Brown]

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


> On 24 May 2016, at 10:25, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Tue, 24 May 2016 09:47:35 -0700
>> Cc: rgm@gnu.org, emacs-devel@gnu.org
>> 
>> On 05/24/2016 08:59 AM, Eli Zaretskii wrote:
>>> I have hard time believing this is a browser issue
>> 
>> I don't. There are different kinds of refreshes, and it's possible that 
>> a partial refresh won't give you a new page at the same time that a full 
>> refresh would.
> 
> That makes no sense at all.  It's the same browser and the same Web
> page.  How can the browser know to refresh it in one case, but not in
> the other?

Because the refresh button doesn’t ask the web server for a new copy of the page; it instead asks the local cache to check and see if it thinks a new copy of the web page is needed. There are many circumstances where the local cache controller can ask the web server and get back what is effectively the wrong answer. C-F5 is a standard command that tells the web browser to have the local cache get a new copy of the page, without asking the web server if it can use the cached copy instead. In practice, this sort of thing happens in certain corners often enough that many people have developed the habit of always using the reload-dammit command when they’re sure they want a fresh page (see Kaushal Modi’s message, for example).

Debbugs could be changed to always give out a new copy of the page, with the concomitant increase in load you might expect from always bypassing the cache. It could presumably be changed to never give out the wrong answer, but (if this is what is happening in this case — it’s hard to tell without someone trying) that depends on specific effort being put into debbugs.

I hope that helps.
~Chad


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

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Eli Zaretskii]

> From: Chad Brown <yandros@gmail.com>
> Date: Tue, 24 May 2016 18:22:33 -0700
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
>  That makes no sense at all. It's the same browser and the same Web
>  page. How can the browser know to refresh it in one case, but not in
>  the other?
> 
> Because the refresh button doesn’t ask the web server for a new copy of the page; it instead asks the local
> cache to check and see if it thinks a new copy of the web page is needed. There are many circumstances
> where the local cache controller can ask the web server and get back what is effectively the wrong answer.

So you are saying that this always brings the cached copy when a bug
is closed, and always brings the correct copy when a bug is deleted
from the blocking list?  That makes no sense to me: the browser and
the cache don't understand the semantics of each operation at all, so
I don't see how they could do different stuff in each case.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Paul Eggert]

Eli Zaretskii wrote:
> That makes no sense to me: the browser and
> the cache don't understand the semantics of each operation at all

They don't need to. They can rely on non-semantic metadata that the origin web 
server provides, e.g., an entity tag. However, if the origin web server is 
misbehaving when a blocking bug is fixed, or if the browser or intermediate 
cache is misbehaving in that particular case, one could see the symptoms you're 
observing.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Glenn Morris]

The issue (I imagine) is that closing bug #456 which blocks bug #123
does not *directly* affect the status of bug#123. (In contrast, removing
#456 from #123's list of blockers does.) If someone wants to change
this, try looking at blockedby and last_modified in debbug's Status.pm
(but I have no idea how/if any of that propagates to the http modified
headers of CGI output). Obviously this is a debbugs bug, like many
things are, but a trivial one with an easy workaround, so I don't intend
to work on it. (No-one else has ever sent me a debbugs patch for
anything, but if they sent one for this I would apply it, if safe.)

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Glenn Morris]

Technical comments welcome at http://debbugs.gnu.org/23624

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Paul Eggert]

On 05/24/2016 09:47 AM, Paul Eggert wrote:
> this question should be resolvable easily the next time you fix a 
> blocking bug, by trying out Firefox on the bug in question.

I just now tested this with Firefox and it worked as I expected. I 
closed Bug#23612 (a blocking bug) and then visited this web page:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759

Firefox showed the bug as still blocking. I refreshed the web page by 
left-clicking with the mouse on the refresh icon just to the right of 
the URL in the menu bar. Firefox still showed the bug as blocking. I 
then did a shift-left-click on the same icon (a full refresh). Firefox 
updated the web page properly.

So, a full-refresh appears to be enough to work around the problem, at 
least for me (Firefox, Fedora 23 x86-64).

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1400 bytes --]

On 2016-05-25 14:23, Paul Eggert wrote:
> On 05/24/2016 09:47 AM, Paul Eggert wrote:
>> this question should be resolvable easily the next time you fix a blocking bug, by trying out Firefox on the bug in question.
> 
> I just now tested this with Firefox and it worked as I expected. I closed Bug#23612 (a blocking bug) and then visited this web page:
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759
> 
> Firefox showed the bug as still blocking. I refreshed the web page by left-clicking with the mouse on the refresh icon just to the right of the URL in the menu bar. Firefox still showed the bug as blocking. I then did a shift-left-click on the same icon (a full refresh). Firefox updated the web page properly.
> 
> So, a full-refresh appears to be enough to work around the problem, at least for me (Firefox, Fedora 23 x86-64).

Doesn't this indicate a bug in debbugs?

Presumably when you did the simple refresh Firefox queried the server to know if a more up-to-date version of the page was available (using the X-Modified-Since header); it should have received a positive answer, but instead received a negative one (that would be the bug).

Doing a hard refresh forces Firefox to bypass its cache; but ideally, debbugs should respond correctly to Firefox' queries and indicate that the page was in fact modified.

Or am I misunderstanding something?
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 135 bytes --]

On 2016-05-25 14:51, Clément Pit--Claudel wrote:
> using the X-Modified-Since header

This should have been 'If-Modified-Since'


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Dmitry Gutov]

On 05/25/2016 09:51 PM, Clément Pit--Claudel wrote:

>> So, a full-refresh appears to be enough to work around the problem, at least for me (Firefox, Fedora 23 x86-64).
>
> Doesn't this indicate a bug in debbugs?

It does, but it's unlikely that anybody's going to work on fixing it 
(our debbugs is a heavily customized fork, so we can't rely on the 
upstream in this either).

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Paul Eggert]

On 05/25/2016 11:51 AM, Clément Pit--Claudel wrote:
> Presumably when you did the simple refresh Firefox queried the server 
> to know if a more up-to-date version of the page was available (using 
> the X-Modified-Since header); it should have received a positive 
> answer, but instead received a negative one (that would be the bug). 

Yes, in this case the request headers include "Cache-Control: max-age=0" 
and "If-Modified-Since: |Tue, 24 May 2016 17:50:01 GMT". Firefox is 
using If-Modified-Since because the HTTP response from debbugs.gnu.org 
for <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759> contains a 
header line "Last-Modified: Tue, 24 May 2016 17:50:01 GMT". This 
Last-Modified time is the|time that Glenn added Bug#23612 as a blocker 
for Bug#|19759|. However, that's the wrong time value: the Last-Modified 
time should be at least Wed, 25 May 2016 17:45:21 GMT, which is when I 
fixed the blocking bug #23611, as this fix caused a change to the 
contents of <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759>.

> Doing a hard refresh forces Firefox to bypass its cache; but ideally, 
> debbugs should respond correctly to Firefox' queries and indicate that 
> the page was in fact modified. 

Yes, the bug is clearly on the debbugs side here. That being said, the 
workaround is to use a shift-reload, which causes Firefox to specify 
"cache-control: no"in its request, which in turn causes debbugs to 
recalculate the page.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 25 May 2016 14:51:32 -0700
> 
> > Doing a hard refresh forces Firefox to bypass its cache; but ideally, 
> > debbugs should respond correctly to Firefox' queries and indicate that 
> > the page was in fact modified. 
> 
> Yes, the bug is clearly on the debbugs side here. That being said, the 
> workaround is to use a shift-reload, which causes Firefox to specify 
> "cache-control: no"in its request, which in turn causes debbugs to 
> recalculate the page.

The bug seems to be that the removal of a closed bug from the blockers
list takes several hours, which is much more than one can be
reasonably expect to wait.  For example, one bug was closed yesterday
6.5 hours before I got to refreshing the list, and then just clicking
the refresh icon showed the updated list.  By contrast, explicitly
removing a bug from the list by a debbugs command results in an
instant update that doesn't need any workarounds.

That said, all this thread is a tempest in a teapot, because adding a
bug to the list (if it becomes open again) takes just a few moments.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Paul Eggert]

Eli Zaretskii wrote:
> The bug seems to be that the removal of a closed bug from the blockers
> list takes several hours

That's not been my experience. There is never a several-hour wait. If I close 
the blocking bug B via email, and wait a minute or two and verify that it's 
closed by visiting its bug page and forcing a refresh, and then visit 
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759>, what I observe is that 
Bug#19759 still lists B as blocking (due to the debbugs bug). If I refresh the 
Bug#19759 page in the routine way it will continue to list B as blocking. If I 
do a full refresh (by shift-left-mouse-click) then the Bug#19759 page will no 
longer list B as blocking; this is always immediate, assuming B has been closed 
already.

> adding a
> bug to the list (if it becomes open again) takes just a few moments.

Sure, but it's easy to forget to add B as a blocker, and indeed the person 
reopening B may not even know that B was a blocker and should become a blocker 
again. In contrast, simply closing B in the first place will mean that reopening 
B later will do the right thing without further thought.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Eli Zaretskii]

> Cc: clement.pit@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 25 May 2016 22:08:30 -0700
> 
> Eli Zaretskii wrote:
> > The bug seems to be that the removal of a closed bug from the blockers
> > list takes several hours
> 
> That's not been my experience. There is never a several-hour wait. If I close 
> the blocking bug B via email, and wait a minute or two and verify that it's 
> closed by visiting its bug page and forcing a refresh, and then visit 
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759>, what I observe is that 
> Bug#19759 still lists B as blocking (due to the debbugs bug). If I refresh the 
> Bug#19759 page in the routine way it will continue to list B as blocking. If I 
> do a full refresh (by shift-left-mouse-click) then the Bug#19759 page will no 
> longer list B as blocking; this is always immediate, assuming B has been closed 
> already.

I was talking about a simple refresh, not forced refresh.

And it looks like a problem is more complex than I thought: on one
machine I tried this even 24 hours was not enough to refresh the page.

> > adding a
> > bug to the list (if it becomes open again) takes just a few moments.
> 
> Sure, but it's easy to forget to add B as a blocker, and indeed the person 
> reopening B may not even know that B was a blocker and should become a blocker 
> again. In contrast, simply closing B in the first place will mean that reopening 
> B later will do the right thing without further thought.

You can rely on me: I won't forget.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Paul Eggert]

On 05/26/2016 08:09 AM, Eli Zaretskii wrote:

> And it looks like a problem is more complex than I thought: on one
> machine I tried this even 24 hours was not enough to refresh the page.

The number of hours is not that relevant. If nobody does a full refresh, 
and nobody edits Bug#19759 more directly, that web page can stay wrong 
for weeks. That's how debbugs works.

In contrast, full-refresh fixes the problem right away, without having 
to make otherwise-superfluous-and-arguably-misleading edits to Bug#19759.

> You can rely on me: I won't forget.

I'm not worried about you! I'm worried about the rest of us -- the mere 
mortals.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Eli Zaretskii]

> Cc: clement.pit@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 26 May 2016 08:27:40 -0700
> 
> On 05/26/2016 08:09 AM, Eli Zaretskii wrote:
> 
> > And it looks like a problem is more complex than I thought: on one
> > machine I tried this even 24 hours was not enough to refresh the page.
> 
> The number of hours is not that relevant. If nobody does a full refresh, 
> and nobody edits Bug#19759 more directly, that web page can stay wrong 
> for weeks. That's how debbugs works.
> 
> In contrast, full-refresh fixes the problem right away, without having 
> to make otherwise-superfluous-and-arguably-misleading edits to Bug#19759.

So you are saying that to see the page refreshed I need to wait for
someone to force debbugs to refresh it?  Beautiful!

> > You can rely on me: I won't forget.
> 
> I'm not worried about you! I'm worried about the rest of us -- the mere 
> mortals.

You can all rely on me.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Paul Eggert]

On 05/26/2016 08:48 AM, Eli Zaretskii wrote:
> So you are saying that to see the page refreshed I need to wait for
> someone to force debbugs to refresh it?

Not at all. You don't need to wait. You can easily force debbugs to 
refresh it yourself, by doing a shift-reload from Firefox. Shift-reload 
doesn't make any changes to the debbugs database; it merely fixes the 
web page. And (at least for me) it's easier than fiddling with the list 
of which blocks block what.

I suppose you're using some sort of Emacs UI to alter the blocking bugs 
list? If so, perhaps someone could add a button to that UI that says 
"Recalculate the debbugs web page for Bug#N", where pressing the button 
would do the equivalent of a shift-reload from Firefox.

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[John Wiegley]

>>>>> Paul Eggert <eggert@cs.ucla.edu> writes:

> Not at all. You don't need to wait. You can easily force debbugs to refresh
> it yourself, by doing a shift-reload from Firefox. Shift-reload doesn't make
> any changes to the debbugs database; it merely fixes the web page. And (at
> least for me) it's easier than fiddling with the list of which blocks block
> what.

> I suppose you're using some sort of Emacs UI to alter the blocking bugs
> list? If so, perhaps someone could add a button to that UI that says
> "Recalculate the debbugs web page for Bug#N", where pressing the button
> would do the equivalent of a shift-reload from Firefox.

Paul, is it acknowledged that this behavior is wrong and a bug, and should be
fixed?  Adding a button to the UI should not be necessary.

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

Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch

[Paul Eggert]

On 05/26/2016 09:43 AM, John Wiegley wrote:
> Paul, is it acknowledged that this behavior is wrong and a bug, and should be
> fixed?

Sure, but what we're hearing from our debbugs expert is "good luck with 
that". Apparently debbugs is not going to be fixed. Perhaps we should 
change our bug-reporting mechanism to something else, but in the 
meantime we need to deal with this relatively-minor gotcha.