headers
Paul Walker | 6 Jan 2005 00:37
Picon
Picon

Re: Mutt Bug Tracking System Frozen.

On Wed, Jan 05, 2005 at 11:11:03PM +0100, Thomas Roessler wrote:

> It is not clear to me what the best way forward for managing mutt
> bugs would be.  Obviously, the e-mail based approach we have been
> using so far is not an option at this point.

I'm afraid I can't offer any hosting; however, would creating a SourceForge
project to use their feature and bug tracking systems be a viable way
forwards?

(I wouldn't suggest using their CVS, since last time I tried it was very
unreliable to update from.)

--

-- 
Paul

I've come to dread my memory playing tricks on me. Whenever it says `pick a
card, any card'' I know I'm in for a hell of a time. -- Jake Kesinger
Permalink | Reply | 2 comments |
headers
Brendan Cully | 6 Jan 2005 02:49
Gravatar

Re: Mutt Bug Tracking System Frozen.

On Wednesday, 05 January 2005 at 23:37, Paul Walker wrote:
> On Wed, Jan 05, 2005 at 11:11:03PM +0100, Thomas Roessler wrote:
> 
> > It is not clear to me what the best way forward for managing mutt
> > bugs would be.  Obviously, the e-mail based approach we have been
> > using so far is not an option at this point.
> 
> I'm afraid I can't offer any hosting; however, would creating a SourceForge
> project to use their feature and bug tracking systems be a viable way
> forwards?

This exists now, but we should probably experiment with it a bit
before committing to it. One drawback (?) is that it doesn't allow
email submission. Also, we'll have to see how easy it is to import
the current BTS into sourceforge's.
Permalink | Reply | 0 comments |
headers
Lars Hecking | 6 Jan 2005 10:36
Picon

Re: Mutt Bug Tracking System Frozen.

Paul Walker writes:
[...] 
> (I wouldn't suggest using their CVS, since last time I tried it was very
> unreliable to update from.)

 These problems seem to have been sorted out. Yes, there were major problems
 several times last year.

Brendan Cully writes:
[...] 
> This exists now, but we should probably experiment with it a bit
> before committing to it. One drawback (?) is that it doesn't allow
> email submission. Also, we'll have to see how easy it is to import
> the current BTS into sourceforge's.

 IIRC it requires that submitters have an SF account, i.e. no more
 anonymous submissions.

 I will take a look at the machine that hosts the current system, if
 Thomas lets me, and maybe come up with a suggestion.
Permalink | Reply | 0 comments |
headers
Frederik Eaton | 6 Jan 2005 23:27

phrasing suggestion

(sorry if this is a duplicate, I'm having trouble with my
subscription)

When a user exits the message composition mode, and sees the "Postpone
this message?" prompt, it would be nice if the phrasing of this prompt
made it clear that his choice isn't just between postponing his
message and doing something else, it's between postponing it and
losing everything he just typed. I think changing the phrasing of the
text to something like "Save (postpone) message?" would make it
clearer than the current "Postpone this meessage?", and maybe help
save people from losing data.

Note that there are other, perhaps more natural, ways for a user to
interpret "Postpone this message?" than what it really means in mutt -
e.g. "maybe 'y' is the default and if I answer 'n', that means
'cancel' and I get back to the composition mode" or "maybe there is
another question coming which will ask if I really want to discard the
message"...

Regards,

Frederik
Permalink | Reply | 17 comments |
headers
Thomas Glanzmann | 7 Jan 2005 10:10
Picon
Picon

Re: phrasing suggestion

Hello Frederik,
maybe something like 'Postpone this message? (No discards the message)'
is better, however I have set postpone=no and use P, y and q
to handle it without any questioning.

On the other hand I think, that we all have lost a message that way and
learned that hard way what *not* todo.

Sincerely,
	Thomas
Permalink | Reply | 1 comment |
headers
Frederik Eaton | 9 Jan 2005 09:48

Re: phrasing suggestion

On Fri, Jan 07, 2005 at 10:10:47AM +0100, Thomas Glanzmann wrote:
> Hello Frederik,
> maybe something like 'Postpone this message? (No discards the message)'
> is better, however I have set postpone=no and use P, y and q
> to handle it without any questioning.

Hmm, well, I was trying to keep the question short - I don't think one
wants to see two sentences every time, but then I'm not a UI person.
How about just 'Save this message?'? It conflicts with other
terminology (?), but maybe that doesn't matter. Maybe 'Save/postpone
this message?'. Also, I could reconfigure it for myself like you've
done (probably with postpone=yes), but I'd like to talk about getting
a good default behavior for new and casual users.

> On the other hand I think, that we all have lost a message that way
> and learned that hard way what *not* todo.

Yeah, that's the thing. Reading through the documentation, I've come
to the conclusion that it's impossible not to learn the hard way.
There's no description of the message and what it means, there's
nothing that says "no" means "discard". And data loss is no good. But
even if it were in the documentation, I think it would still be
unsatisfactory. Sometimes when ... out of it ... I'm still tricked by
the phrasing of that question - I hit 'q' by accident (I use dvorak)
and then 'n' thinking that 'n' means cancel before I remember, and I
lose my message - and I have friends that do the same on occasion.

Frederik
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Roessler | 10 Jan 2005 05:00

[2005-01-10] CVS repository changes

This message was generated and sent automatically.  It contains a
summary of the CVS commits over the last 48 hours.  These changes
should be propagated to the public repository within at most a day
or two.  Most probably, they have already been propagated.

2005-01-09 15:35:51  Thomas Roessler  <roessler <at> does-not-exist.org>
(roessler)

	* doc/muttbug.man, muttbug.sh.in: Replace muttbug and its
	documentation by a note that acknowledges the shut down of the
	bug tracking system.
Permalink | Reply | 0 comments |
headers
Derek Martin | 10 Jan 2005 06:41

Re: phrasing suggestion

On Thu, Jan 06, 2005 at 02:27:26PM -0800, Frederik Eaton wrote:
> When a user exits the message composition mode, and sees the "Postpone
> this message?" prompt, it would be nice if the phrasing of this prompt
> made it clear that his choice isn't just between postponing his
> message and doing something else, it's between postponing it and
> losing everything he just typed. 

Since others have voiced at least some agreement to this thread, I'll
add my $.02 and just say that the current behavior seems both
satisfactory and obvious.  You do, after all, get to the postpone
prompt by pressing 'q' (by default) to exit message composition.
Assuming that you want to do this, I don't see what other options
could exist besides postponing or aborting.  Unless you are unfamiliar
with the definitions of the words "exit" and/or "postpone", I don't
really see where there's any opportunity for confusion.  IMNSHO, I see
no need for a change.

--

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.
Permalink | Reply | 14 comments |
headers
Mads Martin Joergensen | 11 Jan 2005 08:42
Picon

Bug in PLAIN auth over SSL with sasl

Hey all,

I'm seing a bug in the sasl plain method implementation when using PLAIN
auth over SSL instead of LOGIN.

Version 1.4.1 and 1.5.6 both exhibit the same behaviour I might add.

Is it something known? In that case is there patches floating around? If
it's not, then I can aid in debugging.

--

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.
Permalink | Reply | 6 comments |
headers
Brendan Cully | 11 Jan 2005 16:23
Gravatar

Re: Bug in PLAIN auth over SSL with sasl

On Tuesday, 11 January 2005 at 08:42, Mads Martin Joergensen wrote:
> Hey all,
> 
> I'm seing a bug in the sasl plain method implementation when using PLAIN
> auth over SSL instead of LOGIN.
> 
> Version 1.4.1 and 1.5.6 both exhibit the same behaviour I might add.
> 
> Is it something known? In that case is there patches floating around? If
> it's not, then I can aid in debugging.

I'm not aware of the bug. I don't usually use that method, but I just
tried it here and it seems to work. Can you provide more information?
Permalink | Reply | 5 comments |

Gmane