FOR-RELEASE.W32

FOR-RELEASE.W32

[Juanma Barranquero]

As Richard has said that Emacs-on-Windows problems shouldn't delay the
release, Lennart and I have been thinking of adding a file
(tentatively named admin/FOR-RELEASE.W32) listing things that would be
nice to have before releasing a binary tarball for Windows.

Of course, there's no guarantee any of the listed things would be implemented...

Any objection/addition/change to name/intent/contents?

-- 
                    /L/e/k/t/u



This file contains task needed before the release on W32.

* TO BE DONE SHORTLY BEFORE RELEASE

* NEW FEATURES

* FATAL ERRORS

** Emacs crashes accessing JPEG images.

Emacs on Windows can crash when reading a JPEG image; the reason is
having two different versions of the file-handling run-time code, one
on the Emacs executable and the other on the image library, which can
happen when mixing a MSVC build of Emacs with a MinGW build of the
image libraries.  The fix is straightforward and has already been
posted on the developers' list, but it is on the back burner waiting
for a legal comment by RMS or an alternate implementation (we're
speaking about 30 lines of code or so).

* BUGS

** make-network-process consumes excessive CPU.

TCP/IP server processes created with `make-network-process' consume
excessive CPU on some Windows environments.  CPU time uses of 50%
and 100% have been observed on different Window XP configurations.

* DOCUMENTATION

** W32 specifics are not all documented.

\f
Local variables:
mode: outline
End:

Re: FOR-RELEASE.W32

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> As Richard has said that Emacs-on-Windows problems shouldn't delay
> the release, Lennart and I have been thinking of adding a file
> (tentatively named admin/FOR-RELEASE.W32) listing things that would
> be nice to have before releasing a binary tarball for Windows.

Personally, I think really bad problems on Windows should at least
delay the release of a Windows binary: Emacs is one of the most
important migration applications to GNU systems: once a Windows user
uses Emacs for his editing tasks (and utf-8 is increasing our chances
here), he'll be likely to install the GNU utilities (MSYS or Cygwin)
so that many of Emacs' external commands will work.  And then the step
to going GNU all the way is rather small.

In my opinion, a good Windows Emacs is useful for getting people to
use GNU.  That does not mean that Windows problems should delay
releasing 22.1 for Unix-type systems, but I would tend not to release
Windows binaries that are deficient.  Even if that means that such
binaries will only appear with 22.2 or so.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: FOR-RELEASE.W32

[Juanma Barranquero]

On 8/9/05, David Kastrup <dak@gnu.org> wrote:

> Personally, I think really bad problems on Windows should at least
> delay the release of a Windows binary

Well, I obviously agree. I'd oppose as strongly as possible the
release of a Windows binary that crashes on (insert-image-file
"c:/test/image.png"), for example.

> Even if that means that such
> binaries will only appear with 22.2 or so.

Trouble is, if a problem is not fixed for 22.1, there's no guarantee
it will be fixed for 22.2+. The number of people hacking Emacs on
Windows is small and varies slowly.

I try to tackle every Windows problem I have an idea how to approach.
There are some where I'm just at loss. Take the problem with TCP/IP
servers and excessive CPU use, for example. The code for event
handling and polling and the like is complex. I'll try my hand at it,
but I don't have much hope.

-- 
                    /L/e/k/t/u

Re: FOR-RELEASE.W32

[Jason Rumney]

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

David Kastrup wrote:

>Juanma Barranquero <lekktu@gmail.com> writes:
>  
>
>>As Richard has said that Emacs-on-Windows problems shouldn't delay
>>the release, Lennart and I have been thinking of adding a file
>>(tentatively named admin/FOR-RELEASE.W32) listing things that would
>>be nice to have before releasing a binary tarball for Windows.
>>    
>>
>
>Personally, I think really bad problems on Windows should at least
>delay the release of a Windows binary:
>  
>
None of these problems make Emacs unusable. The JPEG problem can be 
avoided by compiling with a Free compiler (which we do anyway for binary 
releases). The high CPU usage for server sockets can be avoided by not 
using server sockets. Perhaps that means we continue to recommend 
gnuserv to Windows users in 22.1, but it should not mean that we 
withhold Emacs binaries for a much awaited version with many 
improvements over 21.x.


[-- Attachment #1.2: Type: text/html, Size: 1367 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: FOR-RELEASE.W32

[Juanma Barranquero]

On 8/9/05, Jason Rumney <jasonr@gnu.org> wrote:

>  None of these problems make Emacs unusable.

No, no unusable. However...

> The JPEG problem can be avoided
> by compiling with a Free compiler (which we do anyway for binary
> releases).

...that's not entirely true. We don't distribute the libraries' DLLs.
Matching a GCC-built Emacs with some MSVC-built libraries could expose
the same problem.

> The high CPU usage for server sockets can be avoided by not using server
> sockets. Perhaps that means we continue to recommend gnuserv to Windows
> users in 22.1, but it should not mean that we withhold Emacs binaries for > a much awaited version with many improvements over 21.x.

FWIW, I agree (that's why I didn't mention this item in my answer to David).

-- 
                    /L/e/k/t/u

Re: FOR-RELEASE.W32

[Jason Rumney]

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

Juanma Barranquero wrote:

>On 8/9/05, Jason Rumney <jasonr@gnu.org> wrote:
>  
>
>> None of these problems make Emacs unusable.
>>    
>>
>
>No, no unusable. However...
>
>  
>
>>The JPEG problem can be avoided
>>by compiling with a Free compiler (which we do anyway for binary
>>releases).
>>    
>>
>
>...that's not entirely true. We don't distribute the libraries' DLLs.
>Matching a GCC-built Emacs with some MSVC-built libraries could expose
>the same problem.
>  
>
OK, so we release the binary without JPEG support. It's still better 
than not releasing at all.


[-- Attachment #1.2: Type: text/html, Size: 1130 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: FOR-RELEASE.W32

[Juanma Barranquero]

On 8/9/05, Jason Rumney <jasonr@gnu.org> wrote:

>  OK, so we release the binary without JPEG support. It's still better than
> not releasing at all.

Sure.

There's something even better: we fix JPEG support. Hell, it is
*already* fixed. :(

-- 
                    /L/e/k/t/u

Re: FOR-RELEASE.W32

[Lennart Borgman]

David Kastrup wrote:

>Juanma Barranquero <lekktu@gmail.com> writes:
>
>  
>
>>As Richard has said that Emacs-on-Windows problems shouldn't delay
>>the release, Lennart and I have been thinking of adding a file
>>(tentatively named admin/FOR-RELEASE.W32) listing things that would
>>be nice to have before releasing a binary tarball for Windows.
>>    
>>
>
>Personally, I think really bad problems on Windows should at least
>delay the release of a Windows binary: Emacs is one of the most
>important migration applications to GNU systems: once a Windows user
>uses Emacs for his editing tasks (and utf-8 is increasing our chances
>here), he'll be likely to install the GNU utilities (MSYS or Cygwin)
>so that many of Emacs' external commands will work.  And then the step
>to going GNU all the way is rather small.
>  
>
I really agree to this.

>In my opinion, a good Windows Emacs is useful for getting people to
>use GNU.  That does not mean that Windows problems should delay
>releasing 22.1 for Unix-type systems, but I would tend not to release
>Windows binaries that are deficient.  Even if that means that such
>binaries will only appear with 22.2 or so.
>
I do not believe that minor problems in w32 or any other port should 
delay the main release. However we do have one major problem 
(emacsclient/server not working) and I think that is so serious that it 
should be fixed before release. Otherwise I think we get a bad 
impression on w32 and that does not help us reach our goals.

I would also suggest handling minor platform specific problems with 
platform specific "subreleases". On such case is the lacking 
documentation for w32 specifics.

I see no reason to handle binaries on w32 different than the source code 
there. Maybe you mean that we just should not make any w32 release until 
major problems are fixed there?

Re: FOR-RELEASE.W32

[Juanma Barranquero]

On 8/9/05, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> However we do have one major problem
> (emacsclient/server not working) and I think that is so serious that it
> should be fixed before release. Otherwise I think we get a bad
> impression on w32 and that does not help us reach our goals.

That's just a non-implemented feature. Emacs has been running on
Windows for years without emacsclient, and people make do with
gnuserv/gnuclient. Of course I think it'd be very nice to have it
working (else I wouldn't be hacking emacsclient right now), but I
hardly would consider it "a major problem".

> I would also suggest handling minor platform specific problems with
> platform specific "subreleases". On such case is the lacking
> documentation for w32 specifics.

That has been done in the past. There were NT Emacs 20.X releases that
weren't synchronized with non-NT Emacs releases.

-- 
                    /L/e/k/t/u

Re: FOR-RELEASE.W32

[Lennart Borgman]

Juanma Barranquero wrote:

>That's just a non-implemented feature. Emacs has been running on
>Windows for years without emacsclient, and people make do with
>gnuserv/gnuclient. Of course I think it'd be very nice to have it
>working (else I wouldn't be hacking emacsclient right now), but I
>hardly would consider it "a major problem".
>  
>
I tend to agree with you and Jason here, I am overestimating this. But 
then a problem is that gnuserv/client is not shipped with Emacs 
(licensing issues if I have understood it correctly, though everything 
is marked as GNU). I think we at least should note this in the manual 
and point to a place where a more official version of gnuserv/client for 
Emacs on w32.

>That has been done in the past. There were NT Emacs 20.X releases that
>weren't synchronized with non-NT Emacs releases.
>  
>
Thanks.

Re: FOR-RELEASE.W32

[Juanma Barranquero]

On 8/9/05, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> But
> then a problem is that gnuserv/client is not shipped with Emacs
> (licensing issues if I have understood it correctly, though everything
> is marked as GNU). I think we at least should note this in the manual
> and point to a place where a more official version of gnuserv/client for
> Emacs on w32.

I agree.

-- 
                    /L/e/k/t/u

Re: FOR-RELEASE.W32

[Jason Rumney]

Lennart Borgman wrote:

> I would also suggest handling minor platform specific problems with 
> platform specific "subreleases". On such case is the lacking 
> documentation for w32 specifics.

If we don't even have the resources to fix two bugs in the W32 port 
before Emacs 22 is released, what makes you think we have the resources 
to manage our own "subreleases"?

These issues are being overblown. There are currently W32 specific 
issues worthy of delaying a release, of Emacs in general, or of W32 
binaries. If there are issues worthy of delaying release, then they 
belong in FOR-RELEASE. If they are not worthy of delaying release, then 
they should be in a TODO file somewhere (a general one, or W32 specific 
depending on the general consensus). Lets not pretend that there is an 
in between state of FOR-RELEASE.W32.

Re: FOR-RELEASE.W32

[Lennart Borgman]

Jason Rumney wrote:

>
> These issues are being overblown. There are currently W32 specific 
> issues worthy of delaying a release, of Emacs in general, or of W32 
> binaries. If there are issues worthy of delaying release, then they 
> belong in FOR-RELEASE. If they are not worthy of delaying release, 
> then they should be in a TODO file somewhere (a general one, or W32 
> specific depending on the general consensus). Lets not pretend that 
> there is an in between state of FOR-RELEASE.W32.

If we can not make a full release on w32 is there not an "in between 
state" then? But I suppose you want to be pragmathic about this. I guess 
I want that too. What I want is that the state of things on w32 should 
be visible so it does not confuse new or even old users or developers. 
Having a workaround is not bad (even if it is not the best).

TODO is in the etc subdir. Does not that make it much less visible than 
admin? Also it does not really seem to contain things for release. I 
still think FOR-RELEASE.W32 is a good and simple name. However if we 
think that is to strong and TODO is too weak then we could try something 
else, but let it be visible! That shows we care and that attracts users.

Re: FOR-RELEASE.W32

[Jason Rumney]

Lennart Borgman wrote:

> I still think FOR-RELEASE.W32 is a good and simple name. However if we 
> think that is to strong and TODO is too weak then we could try 
> something else, but let it be visible! That shows we care and that 
> attracts users.

I think creating a separate file for W32 TODO or FOR-RELEASE items would 
encourage developers who are interested in w32 to only work on those 
issues, which is a bad thing.

It is better to put all W32 issues in TODO, or if they are important for 
release, in FOR-RELEASE, then if only W32 issues are left in 
FOR-RELEASE, RMS can make the decision to move these issues into TODO to 
avoid delaying a release.

Re: FOR-RELEASE.W32

[Juanma Barranquero]

On 8/9/05, Jason Rumney <jasonr@gnu.org> wrote:

> It is better to put all W32 issues in TODO, or if they are important for
> release, in FOR-RELEASE

I've put the image libraries issue and the server processes issues on
FOR-RELEASE, as I consider them important (crashing and hunging up
seems serious enough to me).

> then if only W32 issues are left in
> FOR-RELEASE, RMS can make the decision to move these issues into TODO to
> avoid delaying a release.

Fine by me.

-- 
                    /L/e/k/t/u

Re: FOR-RELEASE.W32

[Juanma Barranquero]

On 8/9/05, Jason Rumney <jasonr@gnu.org> wrote:

> These issues are being overblown.

Not what I intended, for sure.

> There are currently W32 specific
> issues worthy of delaying a release, of Emacs in general, or of W32
> binaries. If there are issues worthy of delaying release, then they
> belong in FOR-RELEASE.

Sorry, this is a contradiction in terms. Per Richard's comments,
stated publicly several times, there exists no such a thing as "w32
specific issues worthy of delaying a release of Emacs in general".

> If they are not worthy of delaying release, then
> they should be in a TODO file somewhere (a general one, or W32 specific
> depending on the general consensus).

OK. The general TODO is fine by me.

> Lets not pretend that there is an
> in between state of FOR-RELEASE.W32.

That's another contradiction: You yourself, in the paragraph quoted
above, have talked about things described as "w32-specific issues
worthy of delaying of a release [...] of W32 binaries." What is the
state for these issues, were they to exist?

All in all, what I want is to keep track of the issues somewhere other
than my e-mail client. TODO is fine. But let's be clear about it,
then: either an issue is general, and can delay a general release, or
it is Windows-specific, and can not delay even a binary release...

-- 
                    /L/e/k/t/u

FOR-RELEASE.W32

[Nick Roberts]

 > As Richard has said that Emacs-on-Windows problems shouldn't delay the
 > release, Lennart and I have been thinking of adding a file
 > (tentatively named admin/FOR-RELEASE.W32) listing things that would be
 > nice to have before releasing a binary tarball for Windows.
 > 
 > Of course, there's no guarantee any of the listed things would be
 > implemented...
 > 
 > Any objection/addition/change to name/intent/contents?

In the admin directory, it seems fairly clear that FOR-RELEASE contains tasks
whose completion are currently considered a prerequisite for a release.  Since
this would not be the case for your proposed file, I suggest that it is called
TODO and placed in the nt directory.

Nick

Re: FOR-RELEASE.W32

[Jason Rumney]

Nick Roberts wrote:

> > As Richard has said that Emacs-on-Windows problems shouldn't delay the
> > release, Lennart and I have been thinking of adding a file
> > (tentatively named admin/FOR-RELEASE.W32) listing things that would be
> > nice to have before releasing a binary tarball for Windows.
> > 
> > Of course, there's no guarantee any of the listed things would be
> > implemented...
> > 
> > Any objection/addition/change to name/intent/contents?
>
>In the admin directory, it seems fairly clear that FOR-RELEASE contains tasks
>whose completion are currently considered a prerequisite for a release.  Since
>this would not be the case for your proposed file, I suggest that it is called
>TODO and placed in the nt directory.
>  
>
nt is a directory for files that are part of the release. admin is the 
appropriate directory for this file of notes for developers, whatever 
its name.

Re: FOR-RELEASE.W32

[Nick Roberts]

 > > > Of course, there's no guarantee any of the listed things would be
 > > > implemented...
 > > > 
 > > > Any objection/addition/change to name/intent/contents?
 > >
 > >In the admin directory, it seems fairly clear that FOR-RELEASE contains
 > >tasks whose completion are currently considered a prerequisite for a
 > >release.  Since this would not be the case for your proposed file, I
 > >suggest that it is called TODO and placed in the nt directory.
 > >  
 > >
 > nt is a directory for files that are part of the release. admin is the 
 > appropriate directory for this file of notes for developers, whatever 
 > its name.

If the listed things have not been implemented then it might be appropriate to
include their details in the release.  Someone might then implement them.
Presumably this is why TODO _is_ part of the release.

Nick

Re: FOR-RELEASE.W32

[Lennart Borgman]

Nick Roberts wrote:

> > As Richard has said that Emacs-on-Windows problems shouldn't delay the
> > release, Lennart and I have been thinking of adding a file
> > (tentatively named admin/FOR-RELEASE.W32) listing things that would be
> > nice to have before releasing a binary tarball for Windows.
> > 
> > Of course, there's no guarantee any of the listed things would be
> > implemented...
> > 
> > Any objection/addition/change to name/intent/contents?
>
>In the admin directory, it seems fairly clear that FOR-RELEASE contains tasks
>whose completion are currently considered a prerequisite for a release.  Since
>this would not be the case for your proposed file, I suggest that it is called
>TODO and placed in the nt directory.
>  
>
We wanted the w32 issues to be visible since we consider them important. 
I think that knowing the state of Emacs on w32 might be important to 
everyone interested in making a good release since whatever we think of 
w32 it is an important platform for many users. Many of those we are 
trying to reach are using this platform now (by force or will).

Re: FOR-RELEASE.W32

[Juanma Barranquero]

On 8/9/05, Nick Roberts <nickrob@snap.net.nz> wrote:

> In the admin directory, it seems fairly clear that FOR-RELEASE
> contains tasks whose completion are currently considered a
> prerequisite for a release.  Since this would not be the case
> for your proposed file, I suggest that it is called TODO and
> placed in the nt directory.

Every prerequisite can be skipped, given enough pressure and lack of
time. At least on the projects I've had the (dis)pleasure to work :)

I don't mind the file begin called FOR-RELEASE.W32, TODO.W32 or
whatever, but I agree with Jason, it's an administrative thing and
belongs in admin/.


-- 
                    /L/e/k/t/u