FOR-RELEASE

FOR-RELEASE

[Glenn Morris]

Comments on the state of FOR-RELEASE:


  ** rcyeske@gmail.com, April 22: Failure to build on OpenBSD macppc.

It has been decided this is a gcc problem particular to this platform,
and can be worked around. I have added a PROBLEMS entry.


  ** Spurious redisplay bug not fixed.

I think we've given up on this for now, to be honest.


 ** michael.ewe@arcor.de, Apr 24: 22.0.98  not starting on Solaris 10/I386

Nobody can reproduce this, in three weeks of trying.


  ** Move some items from magic-mode-alist to magic-fallback-mode-alist.

Stefan moved some items yesterday.


And that's it. Please can have a release or a pretest, or a discussion
about a release or pretest, or a discussion about a discussion, or
something.

Icon displayed wrong

[Richard Stallman]

What happened with the problem cloose reported, of the icon that is
displayed wrong?  If I recall right, Yidong installed a fix, but took
it out because it caused problems.  I don't recall seeing that it was
fixed.

I think some say that the icon is in the wrong format for its file
name.  Can someone convert it to the right format?  Would that fix
this problem, for now?

Re: Icon displayed wrong

[Glenn Morris]

Richard Stallman wrote:

> What happened with the problem cloose reported, of the icon that is
> displayed wrong?  If I recall right, Yidong installed a fix, but took
> it out because it caused problems.  I don't recall seeing that it was
> fixed.

You are mixing up two issues.

The issue for which a fix was installed, then reverted, was the
"crash: x_error_quitter" issue, emacs-devel, 2007/05/10, started by
sds. This issue was never in FOR-RELEASE. I have not followed the
thread, but it seems to still be active.

The icon issue (which is the one that was in FOR-RELEASE) was totally
separate. See the thread "A redisplay bug in 22.0.99?" in emacs-devel,
started 2007/05/11 by Juanma.

> I think some say that the icon is in the wrong format for its file
> name. Can someone convert it to the right format? Would that fix
> this problem, for now?

The icon is fine, and this issue is fixed on the trunk and branch.

Re: FOR-RELEASE

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Comments on the state of FOR-RELEASE:
>
>   ** rcyeske@gmail.com, April 22: Failure to build on OpenBSD macppc.
>
> It has been decided this is a gcc problem particular to this platform,
> and can be worked around. I have added a PROBLEMS entry.
>
>   ** Spurious redisplay bug not fixed.
>
> I think we've given up on this for now, to be honest.
>
>  ** michael.ewe@arcor.de, Apr 24: 22.0.98  not starting on Solaris 10/I386
>
> Nobody can reproduce this, in three weeks of trying.
>
>   ** Move some items from magic-mode-alist to magic-fallback-mode-alist.
>
> Stefan moved some items yesterday.
>
> And that's it. Please can have a release or a pretest, or a discussion
> about a release or pretest, or a discussion about a discussion, or
> something.

I still have no clue what is going on with the release.  RMS, as the
Emacs maintainer, can you at least let us know what's the situation?
Are we waiting for something else to happen, or waiting for the sake
of waiting, or what?

Re: Icon displayed wrong

[Richard Stallman]

    The issue for which a fix was installed, then reverted, was the
    "crash: x_error_quitter" issue, emacs-devel, 2007/05/10, started by
    sds. This issue was never in FOR-RELEASE. I have not followed the
    thread, but it seems to still be active.

Thanks.

That doesn't need to be fixed for 22.1, but we should fix it.
Who is working on it?

    The icon is fine, and this issue is fixed on the trunk and branch.

I will remove that item.  Thanks.

Re: Icon displayed wrong

[James Cloos]

>>>>> "GM" == Glenn Morris <rgm@gnu.org> writes:

GM> The icon is fine, and this issue is fixed on the trunk and branch.

The problem with raw pgm files was fixed, but the cancel.pbm file should
still be replaced.  

A simple:

 mv cancel.pbm cancel.pgm && pgmtopbm <cancel.pgm >cancel.pbm && rm cancel.pgm

Imagemagick's convert utility will also work, if pgmtopbm is not handy.

All of the other bitmap icons are actual bitmaps; cancel should be as well.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Icon displayed wrong

[Glenn Morris]

James Cloos wrote:

>>>>>> "GM" == Glenn Morris <rgm@gnu.org> writes:
>
> GM> The icon is fine, and this issue is fixed on the trunk and branch.
>
> The problem with raw pgm files was fixed, but the cancel.pbm file should
> still be replaced.  

Fine. I've converted it on the trunk; I see no need to do so on the
release branch.

Re: Icon displayed wrong

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Date: Fri, 18 May 2007 20:32:19 -0400
> Cc: Glenn Morris <rgm@gnu.org>, rms@gnu.org
> 
> >>>>> "GM" == Glenn Morris <rgm@gnu.org> writes:
> 
> GM> The icon is fine, and this issue is fixed on the trunk and branch.
> 
> The problem with raw pgm files was fixed, but the cancel.pbm file should
> still be replaced.  

Can you explain why?

Re: Icon displayed wrong

[James Cloos]

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

>> The problem with raw pgm files was fixed, but the cancel.pbm file should
>> still be replaced.  

Eli> Can you explain why?

The images directory has both B/W and Colour versions of each icon.  The
Colour versions are all xpm (X pixmap) files, and the B/W are all pbm
(Portable Bitmap) files.  All except cancel.pbm which has (had, on
trunk, now that Glenn updated it) the bitmap extension but is (was) a
grayscale file using only colours 0 and 255.

Converting it simply makes it match all of the other icons, and it
obviously was intended to be a P4 pbm file when it was first commited;
whoever saved it from Gimp just "typo"ed the SaveAs on that one file.

(Of course, it turns out that that was good for Emacs, since it pointed
out a bug which otherwise probably would not have yet been found.)

If there is any chance of .990 getting simply renamed as 22.1, then I
agree with Glenn's decision not to also make then change on the release
branch.  But it should then get done there for 22.2.

Since the PGM-in-PBM was obviously just a "typo" (mouse-o?), it is just
the Right Thing To Do.  At least on trunk, where it cannot delay the
pending release.  ;^)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Icon displayed wrong

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sat, 19 May 2007 01:07:49 -0400
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> James Cloos wrote:
> 
> > The problem with raw pgm files was fixed, but the cancel.pbm file should
> > still be replaced.  
> 
> Fine. I've converted it on the trunk

The converted image displays differently from the original one: it
looks like it gets its foreground and background colors from the
current frame.  To reproduce, visit the original and the converted PBM
files in a frame that sets non-default colors.  For the record, mine
are set up as follows:

  (add-to-list 'default-frame-alist '(background-color . "gray86"))
  (add-to-list 'default-frame-alist '(foreground-color . "medium blue"))

The original image, by contrast, always displays as black on white.  I
don't know enough about images and tool-bar buttons to say which of
these is the behavior we want.

Re: Icon displayed wrong

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 19 May 2007 03:49:36 -0400
> 
> Eli> Can you explain why?
> 
> The images directory has both B/W and Colour versions of each icon.  The
> Colour versions are all xpm (X pixmap) files, and the B/W are all pbm
> (Portable Bitmap) files.  All except cancel.pbm which has (had, on
> trunk, now that Glenn updated it) the bitmap extension but is (was) a
> grayscale file using only colours 0 and 255.
> 
> Converting it simply makes it match all of the other icons, and it
> obviously was intended to be a P4 pbm file when it was first commited;
> whoever saved it from Gimp just "typo"ed the SaveAs on that one file.

In other words, you are saying it should be converted for consistency.

Note that there are a couple of other *.pbm files in etc/images that
on the branch are not PBM files.  For example, copy.pbm is a PPM
file.  Are we sure they all are due to typo-style mistakes?

> If there is any chance of .990 getting simply renamed as 22.1

There's exactly 0% chance that this will happen, because some source
files need to be modified to change the version number, and the
ChangeLog files need to be marked with the release entry.

> then I
> agree with Glenn's decision not to also make then change on the release
> branch.  But it should then get done there for 22.2.

I actually agree with Glenn's decision not to touch the release
branch; see my other mail in this thread where I report that the
converted image file behaves differently from the original PGM one.
It is these unintended consequences that we should consider when we
discuss changes for non-critical problems.

Re: Icon displayed wrong

[James Cloos]

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

Eli> Note that there are a couple of other *.pbm files in etc/images
Eli> that on the branch are not PBM files.  For example, copy.pbm is a
Eli> PPM file.  Are we sure they all are due to typo-style mistakes?

I see 5 such files: copy.pbm, next-node.pbm, prev-node.pbm, save.pbm and
up-node.pbm.  Each of those has just black and white pixels, exactly
like the PGM version of cancel.pbm.  

So, yes, I do beleive they are also typo-style mistakes.  It is very
easy in the Gimp and XV to hit the wrong version of portable bit/grey/
pix map file when choosing from the popup menus.  I've done it myself.

The pbm icons were intended for bitmap displays (at least the ones
coming from Gnus) and the xpm for colour displays.

I do find it interesting that Emacs displays bitmap icons as foreground/
background masks rather than black/white images, but that does seem
reasonable given the desires to support both light-on-dark and dark-on-
light displays and to support bitmap displays of varying emitter colour.

As such, the display of the unaltered cancel, copy, next-node,
prev-node, save and up-node bitmap icons on light-on-dark bitmap
displays will be drastically different than the rest of the bitmap
icons.  I can't see how that could have been intended.

So those five should be converted with either of:

   ppmtopgm <$old |pgmtoppm >$new && mv $new $old

   convert $old -format PBM $new && mv $new $old

>> If there is any chance of .990 getting simply renamed as 22.1

Eli> There's exactly 0% chance that this will happen, because some
Eli> source files need to be modified to change the version number, and
Eli> the ChangeLog files need to be marked with the release entry.

OK.  I did think that "other than release-process changes" went w/o
saying, but point taken.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Icon displayed wrong

[Jason Rumney]

Eli Zaretskii wrote:
>
> The original image, by contrast, always displays as black on white.  I
> don't know enough about images and tool-bar buttons to say which of
> these is the behavior we want.
>   

It should be consistent with the other toolbar button images.

Re: FOR-RELEASE

[Richard Stallman]

    >  ** michael.ewe@arcor.de, Apr 24: 22.0.98  not starting on Solaris 10/I386
    >
    > Nobody can reproduce this, in three weeks of trying.

As I recall, the last message in the initial discussion was that he
found more details of what was necessary.  Then the issue slept until
I reminded people to look at it.  Then Giorgos Keramidas
<keramida@ceid.upatras.gr> started to look at it, and sent what
appears to be a partial, interim report.

Giorgos, have you finished trying to reproduce this bug?
Have you given up?

Re: Icon displayed wrong

[Eli Zaretskii]

> Date: Sat, 19 May 2007 11:02:27 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Glenn Morris <rgm@gnu.org>, cloos@jhcloos.com,
> 	emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> >
> > The original image, by contrast, always displays as black on white.  I
> > don't know enough about images and tool-bar buttons to say which of
> > these is the behavior we want.
> >   
> 
> It should be consistent with the other toolbar button images.

Well, even I know enough to agree to this principle ;-)

I should have said I didn't know enough to decide whether this was
consistent or not.

Re: FOR-RELEASE

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

>   ** Spurious redisplay bug not fixed.
>
> I think we've given up on this for now, to be honest.

I just checked in an experimental fix into the trunk.

This involves recomputing the window start in the sitation where we
are on a continuation line, instead of simply recentering.

If you are using the trunk, please be on the lookout for redisplay
bugs related to continuation lines.

Re: Icon displayed wrong

[Glenn Morris]

Eli Zaretskii wrote:

>> Eli Zaretskii wrote:
>> >
>> > The original image, by contrast, always displays as black on white.
[...]
>> It should be consistent with the other toolbar button images.
[...]
> I should have said I didn't know enough to decide whether this was
> consistent or not.

I was aware of this difference. I think the current situation on the
trunk is the correct one, with all the PBM icons displaying the same.
But the slight uncertainty, coupled with the fact that no-one ever
complained about the old icons (the bug that went into FOR-RELEASE
just happened to be revealed by the one PGM icon), is why I left the
branch alone. Besides the general principle, of course.

Re: Icon displayed wrong

[David Kastrup]

Glenn Morris <rgm@gnu.org> writes:

> Eli Zaretskii wrote:
>
>>> Eli Zaretskii wrote:
>>> >
>>> > The original image, by contrast, always displays as black on white.
> [...]
>>> It should be consistent with the other toolbar button images.
> [...]
>> I should have said I didn't know enough to decide whether this was
>> consistent or not.
>
> I was aware of this difference. I think the current situation on the
> trunk is the correct one, with all the PBM icons displaying the same.
> But the slight uncertainty, coupled with the fact that no-one ever
> complained about the old icons (the bug that went into FOR-RELEASE
> just happened to be revealed by the one PGM icon), is why I left the
> branch alone. Besides the general principle, of course.

While the half-self-disciplined semi-chaos in the trunk might actually
continue for a while without problems, I think we'll need to appoint
someone to the chore of Emacs 22 release manager (post 22.1, of
course...).  It will mean deciding just when to merge just which bug
fixes after which tests into EMACS_22_BASE, and when to actually do
22.2+ releases.  For the trunk development, discussions may lead to
agreement to solutions.  But release and bugfix merge management are
not a matter of finding an "optimal solution", but rather exercising
some individual judgment.  It would be a complete waste of developer
time to discuss the details about those decisions.

And it will probably not be an overly exciting job.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Icon displayed wrong

[Richard Stallman]

Is the inconsistency in icon style visible in the version that will be
Emacs 22.1?  Does it look bad?

Re: Icon displayed wrong

[Glenn Morris]

Richard Stallman wrote:

> Is the inconsistency in icon style visible in the version that will be
> Emacs 22.1?  Does it look bad?

If you compile an Emacs with very limited image support, so that it
uses the pbm versions of the icons rather than the xpm versions, the
toolbar looks fine. The "odd" icons (eg copy.pbm) that have a slightly
different file type look exactly the same as the other icons. So I
think there is no problem. It's only tidyness that motivates us to
make them all exactly the same file type.

Re: Icon displayed wrong

[Jason Rumney]

Richard Stallman wrote:
> Is the inconsistency in icon style visible in the version that will be
> Emacs 22.1?  Does it look bad?
>   

The prerequisites for hitting this bug are:

1. No XPM support or a monochrome display.
2. User has set the Emacs.tool-bar.attributeForeground XResource to
something other than black.

Point 1 limits the potential audience of the bug to people with X on a
monochome display, and Windows users without the xpm image library. I
don't know how many of the first group exist but I think it will be very
small, and the process for setting XResources is sufficiently difficult
on Windows that anyone capable of doing that is surely capable of
downloading and installing xpm libraries.

In trying to reproduce this bug, I saw another bug that makes the
tool-bar icons inconsistent regardless of whether we replace these icons
or not. Changing the foreground of the tool-bar face in .emacs does not
take effect for the icons that are displayed when Emacs starts. Likewise
when a user uses customize-face to change the tool-bar face, only
tool-bar icons that have not yet been displayed are affected.

Re: Icon displayed wrong

[Richard Stallman]

    The prerequisites for hitting this bug are:

    1. No XPM support or a monochrome display.
    2. User has set the Emacs.tool-bar.attributeForeground XResource to
    something other than black.

Ok, we can ignore it for 22.1.  But please let's put the fixed icons
in 22.2.

Re: Icon displayed wrong

[Glenn Morris]

Richard Stallman wrote:

> Ok, we can ignore it for 22.1.  But please let's put the fixed icons
> in 22.2.

Agreed. The prblem will be remembering to do it; so I've added a
section "Fixes for Emacs 22.2" to FOR-RELEASE on the release branch.

I have the vague feeling there are already some other things that
should be in here...

Re: Icon displayed wrong

[Richard Stallman]

    Agreed. The prblem will be remembering to do it; so I've added a
    section "Fixes for Emacs 22.2" to FOR-RELEASE on the release branch.

Thanks.

    I have the vague feeling there are already some other things that
    should be in here...

I put in another.

I seem to recall suggesting installation of some other things after
the 22.1 release, during the past week.  Can someone look?

Re: FOR-RELEASE

[Giorgos Keramidas]

On 2007-05-19 06:55, Richard Stallman wrote:
>    >  ** michael.ewe@arcor.de, Apr 24: 22.0.98  not starting on Solaris 10/I386
>    >
>    > Nobody can reproduce this, in three weeks of trying.
>
> As I recall, the last message in the initial discussion was
> that he found more details of what was necessary.  Then the
> issue slept until I reminded people to look at it.  Then
> Giorgos Keramidas <keramida@ceid.upatras.gr> started to look at
> it, and sent what appears to be a partial, interim report.
>
> Giorgos, have you finished trying to reproduce this bug?
> Have you given up?

I haven't been able to reproduce the crash.  I am not sure what
causes it, but I don't want to keep other people from moving on
because I failed to reproduce it.

Thanks for the heads up email, and I apologise for taking so
long to reply.

- Giorgos

Re: FOR-RELEASE

[Richard Stallman]

In your efforts, have you been able to try on Solaris 10?
Or are you using Solaris 11?

Re: FOR-RELEASE

[Giorgos Keramidas]

On 2007-05-22 04:30, Richard Stallman <rms@gnu.org> wrote:
> In your efforts, have you been able to try on Solaris 10?
> Or are you using Solaris 11?

I tried with a local `Solaris 10 11/06 s10x_u3wos_10 X86' installation
on my Celeron workstation at home.

Re: FOR-RELEASE

[Richard Stallman]

    I tried with a local `Solaris 10 11/06 s10x_u3wos_10 X86' installation
    on my Celeron workstation at home.

I guess that is as close as we can get.  So I will give up on fixing
this now.

It is just a matter of the tar file EOL issue.  Also, if someone can
write the code by tomorrow to make the new option in rcirc use the
proper window's width, we could have that installed too.

Re: FOR-RELEASE

[Richard Stallman]

    I just checked in an experimental fix into the trunk.

It seems to work.  I've been using the trunk for almost 4 days and
have not seen the bug again.

Would you please put that change into 22.1?

Re: FOR-RELEASE

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     I just checked in an experimental fix into the trunk.
>
> It seems to work.  I've been using the trunk for almost 4 days and
> have not seen the bug again.
>
> Would you please put that change into 22.1?

I think it's a bad idea to add it now, but it's your call.  I've
installed it on the branch.

Anything else?

Re: FOR-RELEASE

[Richard Stallman]

    I think it's a bad idea to add it now, but it's your call.  I've
    installed it on the branch.

There were two bug fixes which I asked this morning to have installed.
And there is the PROBLEMS entry for LINUX_VERSION_CODE that should be
deleted.

Also, I saw some Windows build changes were installed.  I don't know
what they do, so I have asked whether they call for a new pretest.

Re: FOR-RELEASE

[Glenn Morris]

Richard Stallman wrote:

> And there is the PROBLEMS entry for LINUX_VERSION_CODE that should be
> deleted.

Eh? Can you elaborate?

Re: FOR-RELEASE

[Richard Stallman]

    > And there is the PROBLEMS entry for LINUX_VERSION_CODE that should be
    > deleted.

    Eh? Can you elaborate?

Debian reverted the change that this is about,
so we need not say anything about the issue.

I deleted the PROBLEMS item which is no longer needed.