From: David Kastrup <dak@gnu.org>
Cc: snogglethorpe@gmail.com, emacs-devel@gnu.org, miles@gnu.org
Subject: Re: Ok, here is the bug I have been looking for. Kim, not Jan...
Date: Thu, 03 Mar 2005 00:40:04 +0100 [thread overview]
Message-ID: <x5oee18vmz.fsf@lola.goethe.zz> (raw)
In-Reply-To: <m3vf893aqc.fsf@kfs-l.imdomain.dk> (Kim F. Storm's message of "Thu, 03 Mar 2005 00:10:35 +0100")
storm@cua.dk (Kim F. Storm) writes:
> Miles Bader <snogglethorpe@gmail.com> writes:
>
>> I think an explicit decision should be made one way or the other.
>
> Based on the fact that _I_ don't have the necessary time to debug more
> silly xasserts, _I_ made the explicit decision to disable them.
>
>>
>> At the time I enabled it, that was not clear the degree to which it
>> would be a contentious issue (I had been using it personally for ages
>> without any notable problems, and I _did_ ask before I enabled it by
>> default) -- however, now it is.
>
> -- and now it isn't.
I'd have prefered to solve conflicts other than by battling commits,
even though it is more than obvious that this change at least suits
me. At the moment, rather few developers have voiced an opinion in
this matter. It will clearly be a good idea at the time Kim thinks
that the changes in the display engine have reached a state where no
major overhauls are due until the release, and where the remaining
assertions are strictly consistent with the expected behavior, that a
larger _developer_ base will run with xasserts switch on. And I agree
with Miles that it would be beneficial if assertions for which this is
not clear in the current situation get outcommented or moved to a
different class of assertions for now, so that one has the possibility
of running with assertions switched on while getting useful
information.
Assertions should stay in a usable state, that much I agree with
Miles. I don't agree with his opinion that it is a good idea to
enable them in HEAD now. After we branch for release, I would not
object.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
next prev parent reply other threads:[~2005-03-02 23:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-01 4:58 Ok, here is the bug I have been looking for. Kim, not Jan David Kastrup
2005-03-01 8:34 ` Kim F. Storm
2005-03-01 23:24 ` Kim F. Storm
2005-03-01 23:52 ` David Kastrup
2005-03-02 8:47 ` Kim F. Storm
2005-03-02 10:28 ` Miles Bader
2005-03-02 11:01 ` David Kastrup
2005-03-02 11:44 ` Kim F. Storm
2005-03-02 12:12 ` Miles Bader
2005-03-02 23:10 ` Kim F. Storm
2005-03-02 23:40 ` David Kastrup [this message]
2005-03-02 23:58 ` Miles Bader
2005-03-03 12:57 ` Kim F. Storm
2005-03-04 16:48 ` Jan D.
2005-03-06 21:16 ` Kim F. Storm
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=x5oee18vmz.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=miles@gnu.org \
--cc=snogglethorpe@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.