Starting pretest

Starting pretest

[Richard Stallman]

I have made a tentative plan to start pretest on September 1.

I think this is feasible.  I hope that by then we will have fixed the
remaining pending bugs that occur on GNU/Linux.

I ask everyone to please work on the pending bugs energetically.

Re: Starting pretest

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> I have made a tentative plan to start pretest on September 1.

2007 ?

>
> I think this is feasible.  I hope that by then we will have fixed the
> remaining pending bugs that occur on GNU/Linux.
>
> I ask everyone to please work on the pending bugs energetically.

We do, but if you continue to accept new bugs as "blocking for the
release", we will _never_ get to the point of "no pending bugs".

Can't we "close the book" and start pretest on October 1 (2006!!)
-- no matter what?!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Starting pretest

[Andreas Roehler]

Kim F. Storm schrieb:
> Richard Stallman <rms@gnu.org> writes:
>
>   
>> I have made a tentative plan to start pretest on September 1.
>>     
>
> 2007 ?
>
>   
>> I think this is feasible.  I hope that by then we will have fixed the
>> remaining pending bugs that occur on GNU/Linux.
>>
>> I ask everyone to please work on the pending bugs energetically.
>>     
>
> We do, but if you continue to accept new bugs as "blocking for the
> release", we will _never_ get to the point of "no pending bugs".
>
> Can't we "close the book" and start pretest on October 1 (2006!!)
> -- no matter what?!
>
>   

Using the CVS version now for several month:

the feeling is so much better: seems much more stable
than the 21.4.:

Don't hesitate to make the new bundle, to enable
ftp-download.

Thanks a lot for all your fine work!

__
Andreas Roehler

Re: Starting pretest

[Richard Stallman]

The purpose of pretesting is to find more bugs.  There is no point
starting pretest sooner if we are already getting bugs faster than
we can fix them.

Re: Starting pretest

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> The purpose of pretesting is to find more bugs.  There is no point
> starting pretest sooner if we are already getting bugs faster than
> we can fix them.

Except that, even in this late stage, many of the "bugs" you are
asking us to work on are really feature requests.

Re: Starting pretest

[Richard Stallman]

    Except that, even in this late stage, many of the "bugs" you are
    asking us to work on are really feature requests.

I think they are really bug fixes.

Re: Starting pretest

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Except that, even in this late stage, many of the "bugs" you are
>     asking us to work on are really feature requests.
>
> I think they are really bug fixes.

Quite a few are more like "misfeature fixes": they improve Emacs in
case that indeed there _is_ a useful fix.  But on some of those, the
jury more or less is out, and the attempts to improve things don't
lead to a satisfactory situation before several iterations.  I think
we should really stop trying to improve things now that have not
gotten worse since 21.4.

The only exception I think reasonable is for features that now default
to "on", like font lock mode.  But other than that, "no regression"
should be sufficient for starting pretest.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Starting pretest

[Richard Stallman]

    Quite a few are more like "misfeature fixes": they improve Emacs in
    case that indeed there _is_ a useful fix.  But on some of those, the
    jury more or less is out, and the attempts to improve things don't
    lead to a satisfactory situation before several iterations.

Which of the things that have been in FOR-RELEASE since Sep 1 do you
think fit that description?

Re: Starting pretest

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Quite a few are more like "misfeature fixes": they improve Emacs
>     in case that indeed there _is_ a useful fix.  But on some of
>     those, the jury more or less is out, and the attempts to improve
>     things don't lead to a satisfactory situation before several
>     iterations.
>
> Which of the things that have been in FOR-RELEASE since Sep 1 do you
> think fit that description?

Well, I don't have an actual clue about when these problems started
appearing.  And there has been "fixing" going on for a _lot_ that is
not in FOR-RELEASE.

>From the list in FOR-RELEASE, I'd guess the following:

    * WINDOWS SUPPORT BUGS.
    These don't need to be fixed to start pretest, but we call the
    attention of Windows users to fixing them.

    ** henman@it.to-be.co.jp 09 Aug 2006: ispell.el problem on Cygwin.
      (Did we decide that is unreproducible?)

Bug, not misfeature, but likely old?

    ** kitty@dre.vanderbilt.edu Sep 20 says make-frame ignores left
       and top.

Same here.

    * BUGS

    ** yamane@green.ocn.ne.jp: smtpmail.el bug involving base64 encoding.

Bug, likely old.

    ** C-p works properly with fields within the line, but C-n does not.
    (ken.manheimer@gmail.com, Sep 24.)

    ** Should end-of-line get stuck at end of a field?

Both of those are either old misfeatures, or introduced by turning one
old misfeature into a new one.

    ** Text copied between font-lock buffers doesn't refontify
    because of properties that are preserved.  May be fixed now?

Likely old.

    ** Peter_Dyballa@Web.DE, Sep 21: An iso-8859-6 cannot be saved

No idea.

    ** XIM hotkey doesn't work in Emacs.

Likely old.  People that work on those things would have more of a
clue whether these are regressions or rather something that was broken
before already.

And the field movement stuff _clearly_ was of the sort which is not
helping towards a pretest, since a behavior that was seemingly not
satisfactory has been replaced by other behaviors which are seemingly
not satisfactory, and it takes time for the complaints to register.
It was a change of overall strategy, and we don't want those right
now.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Starting pretest

[Richard Stallman]

I asked you how many of the recent entries in FOR-RELEASE
are for problems that fit this criterion:

>     Quite a few are more like "misfeature fixes": they improve Emacs
>     in case that indeed there _is_ a useful fix.

In your response you mentioned only these:

	** C-p works properly with fields within the line, but C-n does not.
	(ken.manheimer@gmail.com, Sep 24.)

	** Should end-of-line get stuck at end of a field?

    Both of those are either old misfeatures, or introduced by turning one
    old misfeature into a new one.

All the rest, you agreed are bugs.  (I think those two are also bugs.)

So I guess that isn't really a major issue.

Re: Starting pretest

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> The purpose of pretesting is to find more bugs.  

Really?

I would rather view the purpose of the pretest as

 Making us "confident" that there are no _serious_ bugs left.


>                                                  There is no point
> starting pretest sooner if we are already getting bugs faster than
> we can fix them.

There will always be bugs!!
Not all bugs need to be fixed to make a release.  
Somebody need to draw the line -- or we will never see a release!

Since there are already _many_ daily users of CVS emacs on "common
platforms", Emacs 22.1 has already gone through infinitely more
testing than any previous emacs release!

IMO we are more than ready to start pretest, so we can have emacs
tested on some of the more unusual platforms (that I suppose the
pretesters may have kept around for that specific purpose!).

For example, we have a recent report of a crash in GC on Cygwin (not
listed in FOR-RELEASE), and there could be crashes on other platforms
that we will only know about once we start the pretest.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Starting pretest

[Romain Francoise]

storm@cua.dk (Kim F. Storm) writes:

> Since there are already _many_ daily users of CVS emacs on "common
> platforms", Emacs 22.1 has already gone through infinitely more
> testing than any previous emacs release!

Yes, now that development versions are distributed in precompiled form
by various distributions/sites, there are literally hundreds of users.

Of course, the fact that it "just works" for those people doesn't mean
that there are no bugs left.  It just means that the bugs that remain
aren't important enough to warrant delaying the release further...

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Starting pretest

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 25 Sep 2006 16:48:56 -0400
> Cc: emacs-devel@gnu.org
> 
> The purpose of pretesting is to find more bugs.  There is no point
> starting pretest sooner if we are already getting bugs faster than
> we can fix them.

The purpose of the pretesting is also to enlarge the number of
machines and configurations in which the new version is run.  Doing so
might very well bring serious bugs we never heard of before, and thus
change our notion about the importance (or, rather, lack thereof) of
the problems we now perceive as bugs that are serious enough to delay
the pretest.

And I do agree with Kim that waiting for when there are no more bugs
will keep us waiting forever.

I say let's start the pretest.

Re: Starting pretest

[Stefan Monnier]

>> The purpose of pretesting is to find more bugs.  There is no point
>> starting pretest sooner if we are already getting bugs faster than
>> we can fix them.

I believe this reasoning is flawed because the rate at which we can fix bugs
depends on many things which may all be (strongly) influenced by the
pretest itself:
- motivation
- amount of info about each bug
- number of outstanding bugs (determines the amount of parallelism available)
- ...


        Stefan

Re: Starting pretest

[Paul Pogonyshev]

Eli Zaretskii wrote:
> I say let's start the pretest.

I second, no, I also agree and I'm certainly not second.  C'mon Richard,
your logic is almost perfect in the political notes you make and you
support democracy there.  Most active developers/maintainers asked for
pretest already (and many did that long ago.)  Can we please start
pretest now or will new Emacs release be delayed by another several
years?

Paul

Re: Starting pretest

[Chong Yidong]

I think we should start the pretest.  The only non-Windows bug left in
FOR-RELEASE is

** Enrico Schwass, Sep 13 help-gnu-emacs: display japanese
   outputdoesnt work quite right

This bug hasn't been reproduced by anyone; there is no recipe for
reproducing the bug; according to him, Emacs compiled by the
distributor from the same sources works fine, indicating a simple
missing library or other trivial configuration issue; we don't even
know what version of Emacs he's using; and he hasn't replied to
Handa's request for clarification.  So I don't think we should wait on
this.

Re: Starting pretest

[Richard Stallman]

    This bug hasn't been reproduced by anyone; there is no recipe for
    reproducing the bug; according to him, Emacs compiled by the
    distributor from the same sources works fine, indicating a simple
    missing library or other trivial configuration issue; we don't even
    know what version of Emacs he's using; and he hasn't replied to
    Handa's request for clarification.  So I don't think we should wait on
    this.

How long has it been since we asked him for that clarification?
We should give up on him after a reasonable time.

Re: Starting pretest

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     This bug hasn't been reproduced by anyone; there is no recipe for
>     reproducing the bug; according to him, Emacs compiled by the
>     distributor from the same sources works fine, indicating a simple
>     missing library or other trivial configuration issue; we don't even
>     know what version of Emacs he's using; and he hasn't replied to
>     Handa's request for clarification.  So I don't think we should wait on
>     this.
>
> How long has it been since we asked him for that clarification?
> We should give up on him after a reasonable time.

October 1.

Even if he replies during the pretest, we can still fix the bug
(assuming there is even a bug).  It's silly for the rest of us to be
sitting around twiddling our thumbs waiting on this.

Re: Starting pretest

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

>> How long has it been since we asked him for that clarification?
>> We should give up on him after a reasonable time.
>
> October 1.
>
> Even if he replies during the pretest, we can still fix the bug
> (assuming there is even a bug).  It's silly for the rest of us to be
> sitting around twiddling our thumbs waiting on this.


Indeed!  

Waiting for progress on _one_ (potential/real) bug should 
not delay the pretest.  Particularly, when we don't have
enough information to make progress on solving it.


BTW, did anyone look at these reports?

> From: Alex Ott <ott@jet.msk.su>
> Subject: emacs from cvs eat my processor on linux
> Date: Tue, 03 Oct 2006 16:02:15 +0400


> From: michael@cadilhac.name (Michaël Cadilhac)
> Subject: SIGSEGV in X export display.
> Newsgroups: gmane.emacs.pretest.bugs
> Date: Tue, 03 Oct 2006 14:41:14 +0200

Also, there is a report about a GC problem on Cygwin (presumably)
related to a tool-bar menu-item which Eli and I have tried to dig
into.  I don't have time to pursue it right now.

Here's one of the first items in the thread:

> From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it>
> Subject: Re: Building Emacs-cvs on Cygwin
> To: Eli Zaretskii <eliz@gnu.org>, "Kim F. Storm" <storm@cua.dk>
> cc: emacs-devel@gnu.org
> Date: Tue, 26 Sep 2006 02:06:17 +0200 (MET DST)


Still, I don't think any of these problems should delay the pretest.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Starting pretest

[Richard Stallman]

    October 1.

    Even if he replies during the pretest, we can still fix the bug
    (assuming there is even a bug).  It's silly for the rest of us to be
    sitting around twiddling our thumbs waiting on this.

I agree.

One other bug is still listed.

Re: Starting pretest

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     October 1.
>
>     Even if he replies during the pretest, we can still fix the bug
>     (assuming there is even a bug).  It's silly for the rest of us to be
>     sitting around twiddling our thumbs waiting on this.
>
> I agree.
>
> One other bug is still listed.

I don't think that all of the developers can fruitfully employ
themselves working exclusively on this particular bug until further
notice.  Starting pretest might result in more bugs to work on being
detected, making the developers be able to employ their skills in
parallel towards the release.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Starting pretest

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     October 1.
>>
>>     Even if he replies during the pretest, we can still fix the bug
>>     (assuming there is even a bug).  It's silly for the rest of us to be
>>     sitting around twiddling our thumbs waiting on this.
>>
>> I agree.
>>
>> One other bug is still listed.
>
> I don't think that all of the developers can fruitfully employ
> themselves working exclusively on this particular bug until further
> notice.  Starting pretest might result in more bugs to work on being
> detected, making the developers be able to employ their skills in
> parallel towards the release.

In particular, the other remaining bug deals with the coding system
code, about which I for one know nothing.