Next pretest, and branching plans

Next pretest, and branching plans

[Chong Yidong]

I will roll the next pretest, 23.1.93, next week, Friday the 26th of
February.

Shortly afterwards, around Monday 1 March, we will make the release
branch, which will be used for all subsequent 23.1.xx pretests, as well
as the final 23.2 release.  Once this branch is made, the feature freeze
will be made "harder".  Except for documentation improvements and
special exceptions (which must first be discussed on emacs-devel, or
with Stefan or myself), the only allowed bugfixes are for regressions
with respect to Emacs 22.

(At a still later date, we will only allow bugfixes for regressions with
respect to Emacs 23.1.)

Once the branch is made, Stefan or myself will announce on emacs-devel
that the trunk is open for Emacs 24 development.  At this point, we can
merge the projects from the pending branch into the trunk, and so forth.
We'll give more details about commit policy for the trunk, and our
general goals for Emacs 24, later.  (Opinions are welcome.)

Once the branch is made, some bugfixes will need to be applied both to
the trunk and to the branch.  This is important, so anyone who has
commit access should take note.

RE: Next pretest, and branching plans

[Drew Adams]

> I will roll the next pretest, 23.1.93, next week, Friday the 26th of
> February.

Never got a Windows binary for the last one, 23.1.92.

Spent a lot of time fiddling with stuff, trying to help test bugs and bug fixes
(e.g. #5478) without the latest binary. Certainly couldn't file any new,
pretest-related bugs.

If pretest feedback from Windows users is at all useful or important to you,
then you might consider this a loss. If not, just keep on rolling...

Re: Next pretest, and branching plans

[Leo]

On 2010-02-18 15:29 +0000, Drew Adams wrote:
>> I will roll the next pretest, 23.1.93, next week, Friday the 26th of
>> February.
>
> Never got a Windows binary for the last one, 23.1.92.
>
> Spent a lot of time fiddling with stuff, trying to help test bugs and bug fixes
> (e.g. #5478) without the latest binary. Certainly couldn't file any new,
> pretest-related bugs.
>
> If pretest feedback from Windows users is at all useful or important to you,
> then you might consider this a loss. If not, just keep on rolling...

Is a policy to provide a binary for windows? There's no binary for
GNU/Linux, OSX and many others.

But when I was using Windows, I have found the following two sources
that provide excellent binary for windows.

http://code.google.com/p/emacs-for-windows/
http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip

Cheers,
Leo

Re: Next pretest, and branching plans

[Sean Sieger]

    http://code.google.com/p/emacs-for-windows/

I'll have try this one, thank you.

    http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip

Huh?  Look at the date stamp.  This used to be a good resource.

RE: Next pretest, and branching plans

[Drew Adams]

>     http://code.google.com/p/emacs-for-windows/
> 
> I'll have try this one, thank you.
>     
>     http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/e
>     macs-from-cvs-091015.zip
> 
> Huh?  Look at the date stamp.  This used to be a good resource.

Neither represents the 23.1.92 pretest, AFAIK. The former says:

  GNU Emacs 23.1.91.1 (i386-mingw-nt5.1.2600)
   of 2010-01-02 on PRETEST

Yidong announced the 23.1.92 pretest on 2010/01/29.

Re: Next pretest, and branching plans

[Sean Sieger]

Sean Sieger <sean.sieger@gmail.com> writes:

        http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip

    Huh?  Look at the date stamp.  This used to be a good resource.

I'm sorry for this comment, Lennart.  It didn't come out right.

Re: Next pretest, and branching plans

[Lennart Borgman]

On Sun, Feb 28, 2010 at 1:36 PM, Sean Sieger <sean.sieger@gmail.com> wrote:
> Sean Sieger <sean.sieger@gmail.com> writes:
>
>        http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip
>
>    Huh?  Look at the date stamp.  This used to be a good resource.
>
> I'm sorry for this comment, Lennart.  It didn't come out right.


No problem. I have just been caught in too much things to get the
uploads working without problem again. It will work again in a while.

RE: Next pretest, and branching plans

[Drew Adams]

> > If pretest feedback from Windows users is at all useful or 
> > important to you, then you might consider this a loss.
> > If not, just keep on rolling...
> 
> Is a policy to provide a binary for windows? There's no binary for
> GNU/Linux, OSX and many others.

I cannot speak to what the "policy" is, or whether there even is a policy. I
make no claim about policy.

GNU Emacs does publish this, FWIW:
http://alpha.gnu.org/gnu/emacs/pretest/windows/.
The README there (from 2010/01/03) says, "This directory contains precompiled
distributions for GNU Emacs on Windows".

That is, GNU Emacs publishes a directory that has _only_ Windows binaries.

No, the README does not claim that the directory includes a binary of the latest
pretest. And it did not include a binary for the previous pretest (23.1.91)
either, until we reminded about it a few times and Jason found time to create
and post it (thank you).

But prior to that, AFAIK, it generally _has_ included pretest binaries.

I repeat: *IF* such feedback from Windows users is important to Emacs
development, then you might consider that not posting a binary will reduce
useful feedback.

Speaking for myself only, that will be the case. As an example, I recently spent
some time with Michael A. trying to debug and fix bug #5478, and we were forced
to test using the previous Windows pretest because the latest was not available.

With no pretest binaries at all, next time perhaps we will need to wait for a
binary of the next release. Or the bug might find someone who wants to not only
fix the bug but also build Emacs on Windows.

Perhaps more importantly, there will be fewer (far fewer, IMO) new bug reports
from Windows users for the latest code. Instead of a pretest, you will, in
effect, just wait until after the release to get such bug reports. The purpose
of the pretest will thus be defeated, except for those Windows pretesters who
are willing to build Emacs.

Speaking for myself again, I have submitted many bug reports for Emacs pretests,
including for the last one (23.1.91). I submitted none for 23.1.92, since there
was no binary. IF you think that bug reports during pretest can be helpful in
general, then this is a loss.

> But when I was using Windows, I have found the following two sources
> that provide excellent binary for windows.
> http://code.google.com/p/emacs-for-windows/
> http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/e
> macs-from-cvs-091015.zip

Yes, and there are other sites that also have, or have had, old Windows
binaries. And people appreciate this. But that is all beside the point.

Those you cite are from 2010/02/02 and 2009/10/15, respectively.
Neither represents the latest pretest. That's the point: the pretest.

If you, Lennart or anyone else builds a pretest binary and posts it, that will
be helpful and appreciated.

RE: Next pretest, and branching plans

[Drew Adams]

Related to this is the fact that bug #5299, a regression, is still outstanding.
It prevents Windows users from using `M-x report-emacs-bug' to file bugs.

Do you really want bug reports from Windows users?

Re: Next pretest, and branching plans

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 20 Feb 2010 09:35:24 -0800
> 
> Related to this is the fact that bug #5299, a regression, is still outstanding.
> It prevents Windows users from using `M-x report-emacs-bug' to file bugs.

I don't know what to fix there.  Email never worked for me on Windows
without some setup.  I use smtpmail, but it will not work without
setting it up for your ISP's mail server.

So, for me, there's no regression: it never worked in previous
versions of Emacs, and it does not work now.

Lennart seems to know what kind of solution worked for you in the
past, so perhaps Lennart could try fixing that, or at least describing
what changed in Emacs that broke that solution, whatever it is.  I
don't have Outlook set up to even try what you describe.

> Do you really want bug reports from Windows users?

Yes, and you know that.

RE: Next pretest, and branching plans

[Drew Adams]

> > Related to this is the fact that bug #5299, a regression, 
> > is still outstanding. It prevents Windows users from
> > using `M-x report-emacs-bug' to file bugs.
> 
> I don't know what to fix there.  Email never worked for me on Windows
> without some setup.  I use smtpmail, but it will not work without
> setting it up for your ISP's mail server.
> 
> So, for me, there's no regression: it never worked in previous
> versions of Emacs, and it does not work now.
> 
> Lennart seems to know what kind of solution worked for you in the
> past, so perhaps Lennart could try fixing that, or at least describing
> what changed in Emacs that broke that solution, whatever it is.  I
> don't have Outlook set up to even try what you describe.

(Perhaps this really belongs in the bug #5299 thread?)

I have no idea what problems you had previously, or what caused the recent
problem.

But I can (and do) use `M-x report-emacs-bug' fine with Emacs releases 22 and 23
(and with pretests, before I reported the bug). It works fine in those releases
(still).

My mail client is Outlook, but I don't know if your mail client has anything to
do with your problems using `M-x report-emacs-bug'.

Something was changed since the Emacs 23.1 release, so that this became broken.
It _is_ a regression, at least for my use case with an external mail client
(Outlook). If it never worked for you, that's unfortunate, but that does not
mean that it never worked.

I don't think (but I don't know) that whatever enabled `report-emacs-bug' to
work previously was Outlook-specific. It might have been something
Windows-specific (dunno). It might have been something specific for use with an
external mail client (any external client) - dunno. But I doubt that it was
something Outlook-specific.

Re: Next pretest, and branching plans

[Lennart Borgman]

On Sat, Feb 20, 2010 at 9:39 PM, Drew Adams <drew.adams@oracle.com> wrote:
>>
>> Lennart seems to know what kind of solution worked for you in the
>> past, so perhaps Lennart could try fixing that, or at least describing
>> what changed in Emacs that broke that solution, whatever it is.  I
>> don't have Outlook set up to even try what you describe.
>
> (Perhaps this really belongs in the bug #5299 thread?)
>
> I have no idea what problems you had previously, or what caused the recent
> problem.
>
> But I can (and do) use `M-x report-emacs-bug' fine with Emacs releases 22 and 23
> (and with pretests, before I reported the bug). It works fine in those releases
> (still).
>
> My mail client is Outlook, but I don't know if your mail client has anything to
> do with your problems using `M-x report-emacs-bug'.
>
> Something was changed since the Emacs 23.1 release, so that this became broken.
> It _is_ a regression, at least for my use case with an external mail client
> (Outlook). If it never worked for you, that's unfortunate, but that does not
> mean that it never worked.


Yes, it is a regression. I spent quite a lot of time finding a simple
useful solution before (the one that is broken now).

It was a w32 only solution so I guess it has been broken by someone
who does not understand the general nature of the OS interface.


> I don't think (but I don't know) that whatever enabled `report-emacs-bug' to
> work previously was Outlook-specific. It might have been something
> Windows-specific (dunno). It might have been something specific for use with an
> external mail client (any external client) - dunno. But I doubt that it was
> something Outlook-specific.


No, the mail client has nothing to do with it. The solution was
general enough to use any mail client on w32.

Re: Next pretest, and branching plans

[Lennart Borgman]

On Sat, Feb 20, 2010 at 8:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> Do you really want bug reports from Windows users?
>
> Yes, and you know that.


I just uploaded new unpatched binaries as I told. However I wonder if
I was uploading the right thing from a pretest point of view.

If I already have Emacs sources checked out (which I have of course)
is there a way to build pretest binaries from what I have? I have no
idea about how the branches and bazaar works for this.

Re: Next pretest, and branching plans

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sun, 21 Feb 2010 01:11:22 +0100
> Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org
> 
> I just uploaded new unpatched binaries as I told. However I wonder if
> I was uploading the right thing from a pretest point of view.
> 
> If I already have Emacs sources checked out (which I have of course)
> is there a way to build pretest binaries from what I have? I have no
> idea about how the branches and bazaar works for this.

The easiest way is to build the pretest sources downloaded from
alpha.gnu.org.

It is also possible to find out the revision number of the tree from
which the pretest tarball was tarred, then "bzr revert" to that
revert, and build it.  But I don't see how this is easier.

Re: Next pretest, and branching plans

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 20 Feb 2010 08:52:50 -0800
> Cc: 
> 
> Perhaps more importantly, there will be fewer (far fewer, IMO) new bug reports
> from Windows users for the latest code. Instead of a pretest, you will, in
> effect, just wait until after the release to get such bug reports. The purpose
> of the pretest will thus be defeated, except for those Windows pretesters who
> are willing to build Emacs.

It's not clear what statistics you have to back this up.  I know for a
fact that several users of the Windows port build Emacs themselves;
what percentage that is of the overall number of people who use the
pretest on Windows should be a subject of survey, not guesswork.

FWIW, tools for such a build are readily available, and help for
setting them up is offered here.  So I could never understand why
people who want to contribute refuse to install the necessary
development environment.  It's not that setting up such a development
environment is hard or needs many hours.

RE: Next pretest, and branching plans

[Drew Adams]

> > Perhaps more importantly, there will be fewer (far fewer, 
> > IMO) new bug reports from Windows users for the latest code.
> >
> > Instead of a pretest, you will, in effect, just wait until
> > after the release to get such bug reports. The purpose
> > of the pretest will thus be defeated, except for those 
> > Windows pretesters who are willing to build Emacs.
> 
> It's not clear what statistics you have to back this up.

To back what up? I cited _myself_ as an example. And I have reported a _lot_ of
bugs, many of which have been fixed. There will therefore be absolutely fewer
(IMO far fewer) bug reports, just counting my own. QED.

> I know for a fact that several users of the Windows port
> build Emacs themselves;

I know that for a fact also. So what?

> what percentage that is of the overall number of people who use the
> pretest on Windows should be a subject of survey, not guesswork.

So go ahead, make such a survey.

But check the overall number of Windows pretest _bug reports_ (and the number of
such bugs that get fixed, and the number of such bugs that you deem important),
not just the number of people who _use_ the Windows pretest.

If you limit your check to those who use the Windows pretest, and if no Windows
binary is posted, then you've obviously limited your check to those who build
Emacs themselves. You will not notice a diminution in _their_ bug reports,
obviously. 'Round and 'round you go...

[French govt official in the 90s: "Since we stopped listening to the New
Caledonian independentists, we no longer hear anything from them."]

But even if you do an accurate survey, and you fairly survey the bugs
_reported_, not just the number of Windows _users_ of a pretest, and you
consider both the number of bug reports and the importance of the bugs reported,
a percentage will only give you part of the story.

That will indicate a relative loss but not the absolute loss of user feedback.
Taking only myself as an example: Even if my bug reports represent a negligible
percentage of the total number of Windows bug reports (which I doubt, but which
might be the case), they nevertheless represent info that could be useful to
Emacs development (that has proven to be the case, in the past). The question
is, do you want that info or not?

The question still is, "Do you really want bug reports from Windows users?"

> FWIW, tools for such a build are readily available, and help for
> setting them up is offered here.  So I could never understand why
> people who want to contribute refuse to install the necessary
> development environment.  It's not that setting up such a development
> environment is hard or needs many hours.

There can be many reasons why someone cannot or does not wish to build Emacs.

And if building it is so simple, and you have already built the pretest, then
why not post your binary of it? Certainly it is at least as easy to post it as
to build it, no? What holds you back? "Tools for such a posting are readily
available".

The purpose of the pretest is only partly to test whether Emacs builds with no
problem. And typically you don't need a zillion build reports for the same
platform to identify bugs affecting building. You don't need every Emacs pretest
tester to build Emacs.

The greater purpose of the pretest is to test _Emacs_ itself, after it is built,
to see what problems might have been introduced by the latest development
changes, 99% of which do not affect building. (No, I don't have statistical
evidence for claiming 99%. Sue me.)

For that, there is no reason to limit the pretest to those who build Emacs
themselves. Especially if you already have a binary available that you can post
(which you apparently do have).

Re: Next pretest, and branching plans

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <sdl.web@gmail.com>, <emacs-devel@gnu.org>
> Date: Sat, 20 Feb 2010 10:35:02 -0800
> 
> > > Perhaps more importantly, there will be fewer (far fewer, 
> > > IMO) new bug reports from Windows users for the latest code.
> > >
> > > Instead of a pretest, you will, in effect, just wait until
> > > after the release to get such bug reports. The purpose
> > > of the pretest will thus be defeated, except for those 
> > > Windows pretesters who are willing to build Emacs.
> > 
> > It's not clear what statistics you have to back this up.
> 
> To back what up?

The claim that the purpose of the pretest will be defeated.

> There can be many reasons why someone cannot or does not wish to build Emacs.

We are here to help overcome whatever difficulties you have.

> And if building it is so simple, and you have already built the pretest, then
> why not post your binary of it?

Building is simple, but packaging and uploading is not.

Re: Next pretest, and branching plans

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> It's not clear what statistics you have to back this up.  I know for a
> fact that several users of the Windows port build Emacs themselves;
> what percentage that is of the overall number of people who use the
> pretest on Windows should be a subject of survey, not guesswork.
>
> FWIW, tools for such a build are readily available, and help for
> setting them up is offered here.  So I could never understand why
> people who want to contribute refuse to install the necessary
> development environment.  It's not that setting up such a development
> environment is hard or needs many hours.

Anyhow, if anyone would like to volunteer to make binaries for the
pretests, please step forward.

RE: Next pretest, and branching plans

[Drew Adams]

> > It's not clear what statistics you have to back this up.  I 
> > know for a fact that several users of the Windows port build
> > Emacs themselves; what percentage that is of the overall
> > number of people who use the pretest on Windows should be a
> > subject of survey, not guesswork.
> >
> > FWIW, tools for such a build are readily available, and help for
> > setting them up is offered here.  So I could never understand why
> > people who want to contribute refuse to install the necessary
> > development environment.  It's not that setting up such a 
> > development environment is hard or needs many hours.
> 
> Anyhow, if anyone would like to volunteer to make binaries for the
> pretests, please step forward.

It sounds like you already have lots of people making Windows pretest binaries -
Eli knows it for a fact, and I don't doubt it.

So what's needed is not a volunteer to make a binary, but a volunteer to post a
binary that s?he has already made.

Re: Next pretest, and branching plans

[Lennart Borgman]

On Sat, Feb 20, 2010 at 7:36 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> It's not clear what statistics you have to back this up.  I know for a
>> fact that several users of the Windows port build Emacs themselves;
>> what percentage that is of the overall number of people who use the
>> pretest on Windows should be a subject of survey, not guesswork.
>>
>> FWIW, tools for such a build are readily available, and help for
>> setting them up is offered here.  So I could never understand why
>> people who want to contribute refuse to install the necessary
>> development environment.  It's not that setting up such a development
>> environment is hard or needs many hours.
>
> Anyhow, if anyone would like to volunteer to make binaries for the
> pretests, please step forward.

I have not made binaries for the pretest, but since I noticed the
request for newer (unpatched) binaries I have uploaded this today to

  http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl

RE: Next pretest, and branching plans

[Drew Adams]

> I have not made binaries for the pretest, but since I noticed the
> request for newer (unpatched) binaries I have uploaded this today to
> 
>   http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl

Thank you, Lennart.

Re: Next pretest, and branching plans

[Lennart Borgman]

On Sat, Feb 20, 2010 at 6:51 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> It's not clear what statistics you have to back this up.  I know for a
> fact that several users of the Windows port build Emacs themselves;
> what percentage that is of the overall number of people who use the
> pretest on Windows should be a subject of survey, not guesswork.


There actually use to be many people downloading prebuilt binaries
from my site (most people prefer my patched version then). But I have
not checked how many downloads there are for a very long time.

Emacs Manuals

[Richard Stallman]

How is progress on updating the Emacs manuals?

Re: Emacs Manuals

[smc]

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

2010/2/18 Richard Stallman <rms@gnu.org>

> How is progress on updating the Emacs manuals?
>
>
>
At least, the Spanish versions of the Emacs manuals are very advanced.

I want to do a request when updating the original English Emacs manuals:
If you change very small pieces of text only for stylistic reasons, don't
forget
that this means some troubles for us the translators to compare the
versions,
since many of theses differences are not relevant in our languages.
Please, do it only if really really necessary.



-- 
Suso
http://gnu.manticore.es

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

Re: Next pretest, and branching plans

[Jason Rumney]

On 22/02/2010 05:46, Chong Yidong wrote:

> Jason, do you think you could down write some instructions?  You could
> put it at the end of admin/make-tarball.txt, or as its own file in the
> admin/ directory.
>    

I don't have access to bzr at the moment, but here are the steps required:

1. Download the source tarball, check signature and unpack.
2. Make sure you have an up to date bzr source tree to use for the admin 
directory.
3. "make install" to create the bin subdirectory with the appropriate files.
4. Copy libxpm.dll from a previous tarball into the bin directory.
5. Check the file admin/nt/README.W32 (from bzr tree) for necessary changes.
6. Make sure 7z.exe is in your PATH, or modify admin/nt/makedist.bat to 
use your preferred zip utility (I found that InfoZip zip.exe does not 
work well, which is why I changed to use 7z.exe)
7. Run admin/nt/makedist.bat. With no args it will give you help on usage.
8. Test the resulting zip files.

Then the process of signing and uploading begins. This is documented in 
the GNU maintainers manual, and is probably the more difficult part of 
the process, particularly if your internet connection is not fast and 
stable and uploads get interrupted.

Re: Next pretest, and branching plans

[Eli Zaretskii]

> Date: Tue, 23 Feb 2010 13:31:25 +0800
> From: Jason Rumney <jasonr@gnu.org>
> CC: Christoph <cschol2112@googlemail.com>, eliz@gnu.org, 
>  emacs-devel@gnu.org
> 
> 6. Make sure 7z.exe is in your PATH, or modify admin/nt/makedist.bat to 
> use your preferred zip utility (I found that InfoZip zip.exe does not 
> work well, which is why I changed to use 7z.exe)

What didn't work well with zip.exe?

> 8. Test the resulting zip files.

What tests did you usually run?

> Then the process of signing and uploading begins. This is documented in 
> the GNU maintainers manual, and is probably the more difficult part of 
> the process, particularly if your internet connection is not fast and 
> stable and uploads get interrupted.

It also requires to register a GPG signature, doesn't it?

Re: Next pretest, and branching plans

[Jason Rumney]

On 24/02/2010 02:29, Eli Zaretskii wrote:
>> 6. Make sure 7z.exe is in your PATH, or modify admin/nt/makedist.bat to
>> use your preferred zip utility (I found that InfoZip zip.exe does not
>> work well, which is why I changed to use 7z.exe)
>>      
> What didn't work well with zip.exe
>    

rem Info-ZIP zip seems to be broken on Windows.
rem It always writes to zip.zip and treats the zipfile argument as one
rem of the files to go in it.
rem zip -9 -r %2-bin-i386 emacs-%1/BUGS emacs-%1/COPYING emacs-%1/README emacs-%1/README.W32 emacs-%1/INSTALL emacs-%1/bin emacs-%1/etc emacs-%1/info emacs-%1/lisp emacs-%1/leim -x emacs.mdp *.pdb *.opt *~ CVS


>> 8. Test the resulting zip files.
>>      
> What tests did you usually run?
>    
Test that the unpacked Emacs runs, along with the other exes in the bin 
directory, and check that the number of files in the zip file is in the 
same ballpark as the previous version.


> It also requires to register a GPG signature, doesn't it?
>    

Yes, your public key needs to be in the GNU keyring to upload to the FTP 
server.

Re: Next pretest, and branching plans

[Richard Stallman]

Have the manuals been updated?  In a release, the manuals should always
be up to date.

Re: Next pretest, and branching plans

[Sean Sieger]

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

Richard Stallman <rms@gnu.org> writes:

    Have the manuals been updated?  In a release, the manuals should always
    be up to date.

I did

emacs -Q --eval "(setq Info-default-directory-list '(\".\"))" \ -f
info-xref-check-all


[-- Attachment #2: manual xrefs --]
[-- Type: application/octet-stream, Size: 2217 bytes --]

In file /usr/local/texlive/2009/texmf/doc/info/dvips.info:
No such node: (kpathsea)Bugs
No such node: (kpathsea)unixtex
No such node: (kpathsea)Bugs
No such node: (kpathsea)Bugs
No such node: (kpathsea)Path specifications
No such node: (kpathsea)MakeTeX script arguments
No such node: (kpathsea)unixtex
No such node: (kpathsea)unixtex
No such node: (kpathsea)unixtex
No such node: (kpathsea)unixtex
In file /usr/local/texlive/2009/texmf/doc/info/fontname.info:
No such node: (dvips)psfonts
In file /usr/local/texlive/2009/texmf/doc/info/kpathsea.info:
Not available to check: (fontu)
Not available to check: (bash)
Not available to check: (autoconf)
Not available to check: (coreutils)
No such node: (web2c)inimf invocation
Not available to check: (gcc)
No such node: (web2c)dmp invocation
No such node: (web2c)DMP invocation
In file /usr/local/texlive/2009/texmf/doc/info/web2c.info:
No such node: (kpathsea)unixtex
No such node: (kpathsea)Copying
No such node: (kpathsea)unixtex
No such node: (kpathsea)Bugs
Not available to check: (autoconf)
Not available to check: (libc)
No such node: (kpathsea)unixtex
No such node: (dvips)psfonts
No such node: (kpathsea)unixtex
No such node: (kpathsea)unixtex
No such node: (kpathsea)unixtex
In file /home/sean/trunk/info/ccmode:
Not available to check: (indent)
In file /home/sean/trunk/info/eintr:
Not available to check: (texinfo)
In file /home/sean/trunk/info/elisp:
Not available to check: (coreutils)
Not available to check: (libc)
In file /home/sean/trunk/info/emacs:
Not available to check: (aspell)
Not available to check: (diff)
Not available to check: (make)
Not available to check: (gdb)
Not available to check: (mailutils)
In file /home/sean/trunk/info/epa:
Not available to check: (gnupg)
In file /home/sean/trunk/info/eudc:
Not available to check: (bbdb)
In file /home/sean/trunk/info/info:
Not available to check: (info-stnd)
Not available to check: (texinfo)
In file /home/sean/trunk/info/message:
Not available to check: (gnupg)
In file /home/sean/trunk/info/pgg:
Not available to check: (gnupg)
In file /home/sean/trunk/info/reftex:
Not available to check: (auctex)
In file /home/sean/trunk/info/tramp:
Not available to check: (bbdb)
done, 563 good, 23 bad

[-- Attachment #3: Type: text/plain, Size: 50 bytes --]


And I'm trying to figure out what to do next ...

Re: Next pretest, and branching plans

[Davis Herring]

> And I'm trying to figure out what to do next ...

The first 34 lines are unrelated to Emacs.  All the error messages that
are for Emacs are saying you're missing other Info files (like, say, those
for `make') and so it can't check that the cross-references in the Emacs
manual point to extant pages in those other manuals.  In short, you've not
found anything wrong, but there were lots of things you couldn't verify.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Next pretest, and branching plans

[Sean Sieger]

    The first 34 lines are unrelated to Emacs.  All the error messages that
    are for Emacs are saying you're missing other Info files (like, say, those
    for `make') and so it can't check that the cross-references in the Emacs
    manual point to extant pages in those other manuals.  In short, you've not
    found anything wrong, but there were lots of things you couldn't verify.

    Davis

Thank you for your time and thought, Davis.

Re: Next pretest, and branching plans

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Have the manuals been updated?  In a release, the manuals should always
> be up to date.

There are still a few items in NEWS that have not yet been documented,
but we are mostly there.

Re: Next pretest, and branching plans

[Richard Stallman]

    There are still a few items in NEWS that have not yet been documented,
    but we are mostly there.

To properly update the manuals calls for more than just to document
the new features.  That is the first step.

The next step is to reread the whole text looking for statements that
have become outdated or incorrect, and fix them.

The next step is to ask other people to do likewise, looking for
double coverage.

Re: Next pretest, and branching plans

[Johan Bockgård]

Chong Yidong <cyd@stupidchicken.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Have the manuals been updated?  In a release, the manuals should always
>> be up to date.
>
> There are still a few items in NEWS that have not yet been documented,
> but we are mostly there.

The Emacs Lisp manual hasn't been updated with 30-bit integers (only the
Emacs manual has (max buffer size)).

2.3.1 Integer Type
3.1 Integer Basics
3.8 Bitwise Operations on Integers

Re: Next pretest, and branching plans

[Glenn Morris]

Johan Bockgård wrote:

> The Emacs Lisp manual hasn't been updated with 30-bit integers (only the
> Emacs manual has (max buffer size)).
>
> 2.3.1 Integer Type
> 3.1 Integer Basics
> 3.8 Bitwise Operations on Integers

Thanks, I tried to update this. It would be great if you could check it.

(Please make a bug report for anything else that is incorrectly marked
as having being updated.)

Re: Next pretest, and branching plans

[Johan Bockgård]

Glenn Morris <rgm@gnu.org> writes:

> Johan Bockgård wrote:
>
>> The Emacs Lisp manual hasn't been updated with 30-bit integers (only the
>> Emacs manual has (max buffer size)).
>>
>> 2.3.1 Integer Type
>> 3.1 Integer Basics
>> 3.8 Bitwise Operations on Integers
>
> Thanks, I tried to update this. It would be great if you could check it.

Looks fine. However, there is another small complication.

In 2.3.1 Integer Type:

> 1073741825       ; Also the integer 1 on a 30-bit implementation.

In 3.1 Integer Basics:

> 1073741825      ; Also the integer 1, due to overflow.

When in fact (type-of 1073741825) => float!

Is this even documented?

Re: Next pretest, and branching plans

[Christoph]

On 2/22/2010 10:31 PM, Jason Rumney wrote:
> On 22/02/2010 05:46, Chong Yidong wrote:
>
>> Jason, do you think you could down write some instructions?  You could
>> put it at the end of admin/make-tarball.txt, or as its own file in the
>> admin/ directory.
>
> I don't have access to bzr at the moment, but here are the steps 
> required:
>
> 3. "make install" to create the bin subdirectory with the appropriate 
> files.

I am trying to package the Windows binaries per Jason's instructions and 
I was wondering about the make install command on Windows: without 
specifying a prefix it installs in the current directory but it also 
does other stuff, for example adding a shortcut to the start menu (by 
calling addpm.exe).

Would it make sense to create a 'make package-install' target that omits 
these things (if there is other stuff besides the shortcut, that is more 
intended for a real installation rather than packaging)? When I am 
packaging I don't want the shortcut created.

Or maybe I am just overlooking an obvious way to do this?

Thanks,
Christoph

Re: Next pretest, and branching plans

[Eli Zaretskii]

> Date: Fri, 12 Mar 2010 20:10:09 -0700
> From: Christoph <cschol2112@googlemail.com>
> 
> I am trying to package the Windows binaries per Jason's instructions and 
> I was wondering about the make install command on Windows: without 
> specifying a prefix it installs in the current directory but it also 
> does other stuff, for example adding a shortcut to the start menu (by 
> calling addpm.exe).

I think "make install" does that even if you do specify the directory
to install in.

> Would it make sense to create a 'make package-install' target that omits 
> these things (if there is other stuff besides the shortcut, that is more 
> intended for a real installation rather than packaging)? When I am 
> packaging I don't want the shortcut created.

Patches are welcome.  While at that, perhaps have that package-install
target run the admin/nt/makedist.bat automatically.

Re: Next pretest, and branching plans

[Christoph]

On 3/13/2010 12:42 AM, Eli Zaretskii wrote:
>> Would it make sense to create a 'make package-install' target that omits
>> these things (if there is other stuff besides the shortcut, that is more
>> intended for a real installation rather than packaging)? When I am
>> packaging I don't want the shortcut created.
>>      
> Patches are welcome.  While at that, perhaps have that package-install
> target run the admin/nt/makedist.bat automatically.
>    
Sounds good, I will take a stab at that.

Thanks,
Christoph

Re: Next pretest, and branching plans

[Stefan Monnier]

> Would it make sense to create a 'make package-install' target that omits
> these things (if there is other stuff besides the shortcut, that is more
> intended for a real installation rather than packaging)? When I am packaging
> I don't want the shortcut created.

To me at least, the name "package-install" would not be helpful.
Something like "install_files_only" would sound more meaningful (or
"install_for_packaging", or ...).


        Stefan

Re: Next pretest, and branching plans

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 13 Mar 2010 13:30:28 -0500
> Cc: emacs-devel@gnu.org
> 
> > Would it make sense to create a 'make package-install' target that omits
> > these things (if there is other stuff besides the shortcut, that is more
> > intended for a real installation rather than packaging)? When I am packaging
> > I don't want the shortcut created.
> 
> To me at least, the name "package-install" would not be helpful.
> Something like "install_files_only" would sound more meaningful (or
> "install_for_packaging", or ...).

I suggest "dist", like in the top-level Makefile.in.  There's no need
for this target without actually producing the binary zip file, so it
should run the makedist.bat script as part of its job.

Re: Next pretest, and branching plans

[Jason Rumney]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Would it make sense to create a 'make package-install' target that omits
>> these things (if there is other stuff besides the shortcut, that is more
>> intended for a real installation rather than packaging)? When I am packaging
>> I don't want the shortcut created.
>
> To me at least, the name "package-install" would not be helpful.
> Something like "install_files_only" would sound more meaningful (or
> "install_for_packaging", or ...).

My preference would be for make install to install the files only, and a
new rule for making shortcuts (install_icons).

Most people who build from source on Windows are probably building in
the same location all the time, so they don't always need to replace the
shortcut. And if they have multiple versions installed, they will want
to maintain the shortcut icons manually to avoid having all the versions
overwrite each other.

Re: Next pretest, and branching plans

[Christoph]

On 3/13/2010 7:38 PM, Jason Rumney wrote:
> Stefan Monnier<monnier@iro.umontreal.ca>  writes:
>    
>>> Would it make sense to create a 'make package-install' target that omits
>>> these things (if there is other stuff besides the shortcut, that is more
>>> intended for a real installation rather than packaging)? When I am packaging
>>> I don't want the shortcut created.
>>>        
>> To me at least, the name "package-install" would not be helpful.
>> Something like "install_files_only" would sound more meaningful (or
>> "install_for_packaging", or ...).
>>      
> My preference would be for make install to install the files only, and a
> new rule for making shortcuts (install_icons).
>
> Most people who build from source on Windows are probably building in
> the same location all the time, so they don't always need to replace the
> shortcut. And if they have multiple versions installed, they will want
> to maintain the shortcut icons manually to avoid having all the versions
> overwrite each other.
>    
For packaging, a make dist rule would also need to copy the dist files 
(libXpm.dll for example) before invoking makedist.bat to really automate 
the entire process.

I agree with you, Jason, that installing shortcuts should be a separate 
step and not the included in the normal make install (for pretty much 
the same reasons you pointed out). But that to me, is a separate issue 
from packaging.

I went ahead and implemented the following so far in my local branch:

- added an option "--distfiles [path to file, for example libXpm.dll]" 
to configure.bat.
Adding those external binaries was the only manual step left in the 
process and can also be automated now.

- added build target 'dist' to makefile.w32-in.
It basically does a 'make install' without creating shortcuts, copies 
the distfiles, i.e. the libXpm.dll to the bin directory and then calls 
'makedist.bat' to create the zip file for distribution.

One problem is that calling makedist.bat means a dependency on the 
trunk, since it is not available in the source tarball. Can we add the 
/admin/nt directory and its contents to the source tarball? Or move the 
files to ../nt? Then, the 'make dist' target would be able to create a 
zip from just the tarball, without having to have the trunk available. 
But since the directory structure is the same, running 'make dist' would 
also work in the trunk itself to easily create binary snapshots of the 
trunk.

The makedist.bat needs to be changed a little because it expects the 
files to be in a folder emacs-xx.x.xx as they are in the tarball, but 
that is a trivial change change to make it more generic and automated.

Also, is there any way to get the version number from a file contained 
in the source tar ball? Then make dist would always output a zip file 
properly named according to the current version.

Any thoughts?

Christoph

Re: Next pretest, and branching plans

[Jason Rumney]

Christoph <cschol2112@googlemail.com> writes:

> One problem is that calling makedist.bat means a dependency on the
> trunk, since it is not available in the source tarball. Can we add the
> /admin/nt directory and its contents to the source tarball? Or move
> the files to ../nt? Then, the 'make dist' target would be able to
> create a zip from just the tarball, without having to have the trunk
> available. But since the directory structure is the same, running
> make dist' would also work in the trunk itself to easily create binary
> snapshots of the trunk.

Moving the files to the top level nt subdirectory would be OK.

> Also, is there any way to get the version number from a file contained
> in the source tar ball? Then make dist would always output a zip file
> properly named according to the current version.

The lib-src makefile contains the version number on Windows.  You could
update admin/admin.el if you want to move this to nt/makefile.

Re: Next pretest, and branching plans

[Eli Zaretskii]

> Date: Sat, 13 Mar 2010 19:50:30 -0700
> From: Christoph <cschol2112@googlemail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> - added an option "--distfiles [path to file, for example libXpm.dll]" 
> to configure.bat.

That's gratuitous, I think: modern Windows shells are powerful enough
to let you write a FOR loop looking for libXpm.dll along PATH.

> Also, is there any way to get the version number from a file contained 
> in the source tar ball? Then make dist would always output a zip file 
> properly named according to the current version.

Again, one of the variants of the FOR command should do the trick.

Re: Next pretest, and branching plans

[Christoph]

On 3/14/2010 11:55 AM, Eli Zaretskii wrote:
>> Date: Sat, 13 Mar 2010 19:50:30 -0700
>> From: Christoph<cschol2112@googlemail.com>
>> Cc: Stefan Monnier<monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>>
>> - added an option "--distfiles [path to file, for example libXpm.dll]"
>> to configure.bat.
>>      
> That's gratuitous, I think: modern Windows shells are powerful enough
> to let you write a FOR loop looking for libXpm.dll along PATH.
>    
This assumes that libXpm.dll is actually somwhere on the PATH, which it 
might or might not be (and I might not put it on the path). I think  the 
command line option for configure.bat is way more flexible for one's 
individual build environment, plus who knows, maybe I want to also 
package libSvg.dll or libWhatever.dll. Now I can do this without having 
to change the code.

>> Also, is there any way to get the version number from a file contained
>> in the source tar ball? Then make dist would always output a zip file
>> properly named according to the current version.
>>      
> Again, one of the variants of the FOR command should do the trick.
>    
Could you elaborate on this solution? Thanks!

Christoph

PS: As for the "powerful Windows shells"...not before Windows 7 (or 
Vista?) with Powershell did Windows ever have a powerful shell... ;)

Re: Next pretest, and branching plans

[Eli Zaretskii]

> Date: Tue, 16 Mar 2010 18:29:17 -0600
> From: Christoph <cschol2112@googlemail.com>
> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, jasonr@gnu.org
> 
> >> - added an option "--distfiles [path to file, for example libXpm.dll]"
> >> to configure.bat.
> >>      
> > That's gratuitous, I think: modern Windows shells are powerful enough
> > to let you write a FOR loop looking for libXpm.dll along PATH.
> >    
> This assumes that libXpm.dll is actually somwhere on the PATH, which it 
> might or might not be (and I might not put it on the path).

If it's not on PATH, it's in the directory where you have the Emacs
binary.

> I think  the 
> command line option for configure.bat is way more flexible for one's 
> individual build environment

Yes, but flexibility comes at a price: one needs _always_ to type that
argument.  Why impose this inconvenience on the user?

> >> Also, is there any way to get the version number from a file contained
> >> in the source tar ball? Then make dist would always output a zip file
> >> properly named according to the current version.
> >>      
> > Again, one of the variants of the FOR command should do the trick.
> >    
> Could you elaborate on this solution? Thanks!

Type "for /?" from the cmd prompt, and read there, especially about
"for /f".  It's too long to post that info here.

> PS: As for the "powerful Windows shells"...not before Windows 7 (or 
> Vista?) with Powershell did Windows ever have a powerful shell... ;)

I was talking about cmd, not about Powershell.

Re: Next pretest, and branching plans

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> If it's not on PATH, it's in the directory where you have the Emacs
> binary.

Well, no. The directory where he has the Emacs binary has just been
created via make install, so it doesn't contain any files that are not
part of Emacs.

> Yes, but flexibility comes at a price: one needs _always_ to type that
> argument.  Why impose this inconvenience on the user?

The make target Christoph is creating is for packaging Emacs. Most users
will have no need to use it.