From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: sdl.web@gmail.com, emacs-devel@gnu.org
Subject: RE: Next pretest, and branching plans
Date: Sat, 20 Feb 2010 10:35:02 -0800 [thread overview]
Message-ID: <557EE28DF6994313B6A4990FEBBD387A@us.oracle.com> (raw)
In-Reply-To: <83iq9rx0bk.fsf@gnu.org>
> > 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).
next prev parent reply other threads:[~2010-02-20 18:35 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-18 11:02 Next pretest, and branching plans Chong Yidong
2010-02-18 15:29 ` Drew Adams
2010-02-20 12:25 ` Leo
2010-02-20 13:05 ` Sean Sieger
2010-02-20 17:02 ` Drew Adams
2010-02-28 12:36 ` Sean Sieger
2010-02-28 15:13 ` Lennart Borgman
2010-02-20 16:52 ` Drew Adams
2010-02-20 17:35 ` Drew Adams
2010-02-20 19:45 ` Eli Zaretskii
2010-02-20 20:39 ` Drew Adams
2010-02-20 20:53 ` Lennart Borgman
2010-02-21 0:11 ` Lennart Borgman
2010-02-21 4:11 ` Eli Zaretskii
2010-02-20 17:51 ` Eli Zaretskii
2010-02-20 18:35 ` Drew Adams [this message]
2010-02-20 19:49 ` Eli Zaretskii
2010-02-20 18:36 ` Chong Yidong
2010-02-20 18:40 ` Drew Adams
2010-02-20 18:54 ` Lennart Borgman
2010-02-20 19:15 ` Drew Adams
2010-02-20 19:08 ` Lennart Borgman
2010-02-18 23:57 ` Emacs Manuals Richard Stallman
2010-02-20 2:46 ` smc
[not found] <4B8147A9.7030504@gmail.com>
[not found] ` <87ljemdzxo.fsf@stupidchicken.com>
2010-02-23 5:31 ` Next pretest, and branching plans Jason Rumney
2010-02-23 18:29 ` Eli Zaretskii
2010-02-23 21:12 ` Jason Rumney
2010-02-24 6:04 ` Richard Stallman
2010-02-24 13:34 ` Sean Sieger
2010-02-24 15:05 ` Davis Herring
2010-02-24 15:18 ` Sean Sieger
2010-02-24 14:05 ` Chong Yidong
2010-02-25 14:26 ` Richard Stallman
2010-02-27 16:52 ` Johan Bockgård
2010-03-03 3:52 ` Glenn Morris
2010-03-05 0:31 ` Johan Bockgård
2010-03-13 3:10 ` Christoph
2010-03-13 7:42 ` Eli Zaretskii
2010-03-13 14:54 ` Christoph
2010-03-13 18:30 ` Stefan Monnier
2010-03-13 19:06 ` Eli Zaretskii
2010-03-14 2:38 ` Jason Rumney
2010-03-14 2:50 ` Christoph
2010-03-14 3:07 ` Jason Rumney
2010-03-14 17:55 ` Eli Zaretskii
2010-03-17 0:29 ` Christoph
2010-03-17 4:14 ` Eli Zaretskii
2010-03-17 12:44 ` Jason Rumney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=557EE28DF6994313B6A4990FEBBD387A@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=sdl.web@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.