[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: smtp crap

From: Drew Adams
Subject: RE: smtp crap
Date: Tue, 11 Oct 2011 17:01:19 -0700

> If the big blocker to getting this right is that we are in pretest and
> therefore cannot make significant change, then surely, given that the
> current proposed solutions are less than adequate, the sensible
> solution is to delay making ANY change to default behaviour until we
> have a good solution. It makes no sense to push forward with something
> that obviously has significant usability issues because of some
> arbitrary pretest condition.

Hear, hear!  Get it right!  Precisely.
Stop worrying about hurrying up the pretest.
Make the release fully baked, something to be proud of.

Take the time to fix bugs that we already know about (e.g. `display-buffer'

Some people (you know who you are) used to scream, groan, and holler when
Richard used to take pains to fix bugs and get the doc right before publishing a
release.  The release cycle was too long, was the complaint.

I did not complain about that, and I wish we still had the same careful policy.
It was a breath of fresh air compared to the usual
throw-some-software-over-the-wall hustle.  There should be no rush to add a 24th
notch to anyone's belt.

This bug-reporting-by-email mess-up was signaled as far back as January 2010
(almost 2 years ago) - see bugs #5299, #7469, and #8595.  Sometimes there was a
bit of a response in terms of trying to fix things.

But to the last go-round, which implemented the config-dialog-from-hell
(reported as far back as Nov 2010 - a year ago), complaints essentially got no
attention.  The problem wrt reporting bugs using `emacs -Q' was passed over in
silence by the maintainers, except for being dismissed by Stefan with "If it
hurts don't do it".

If it weren't for Miles adding his voice recently I'm sure there would not be
this discussion now.  Hard to tell whether the discussion will have any effect,
but at least it seems that people are starting to think about the problem and
possible solutions.

> If the arguments for changing the default
> are valid and the majority of emacs users have to use smtpmail rather
> than local MTAs or don't configure emacs as a MUA and the default MUA
> settings are most often broken due to misconfigured local MTAs, then
> email submission under -Q is already broken for a majority of users
> and has been for some time. Therefore, leaving things as they are
> until the post-24 release is not going to make matters worse.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]