Re: Ultimate trust
Tomas Nordin writes: > Teemu Likonen writes: ... >> I do this: I press "Yes" (to trust "ultimately") but then immediately go >> edit ~/.gnupg/trustlist.txt file and put "!" mark in the beginning of >> that certificate authority's key fingerprint. It marks that key >> untrusted (because I really don't know). Then: "gpgconf --reload >> gpg-agent". > > OK, thanks. That already feels better, knowing I can revert this trust > easily like that. And some better understanding for whats going on. That seems like a UI bug to me -- I'd have thought that there should be a "No" button so that you can stop it repeatedly asking (presumably by automatically doing the same as the above manual procedure). Would anyone happen to know where that should be reported? I have a feeling that I'd want to default that to answering "No", and never see the prompt. The number of people I'm willing to declare ultimate trust in is quite limited, and even for those, I'm not going to do it via some unfamiliar bit of UI that springs up unexpectedly. This strikes me as mildly deranged, and appears to be trying to train users to do the wrong thing. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Restore original keybinding ('r' = reply-to-all)
Jesse Rosenthal writes: ... > If it's not obvious, I'm pretty strongly against Carl's roll-back. I > could, of course, just uncomment my old correction in my .emacs, but I > think it's a change that could hurt users. Those who are more likely to > prefer the reply-all behavior are more likely to be able to change the > defaults. Those who aren't likely to change the defaults are more likely > to be bitten, badly, by a default reply-all behavior. I find the change to the new (only reply to sender) behaviour serously irritating, because it seems I cannot train myself to hit R all the time (which is pretty much what I always want). On the other hand, I'm perfectly capable of customising this, but have something of a fetish for at least trying to live with defaults for a period, so it's my own fault for putting up with it. So, even if I don't personally like it this way round, it is at least fail-safe (well except for the fact that I keep failing to group-reply and then wonder why nobody talks to me any more ;-) Of course, if it turns out that the vast majority of actual users are like me and would prefer to do r and then edit the To/Cc if it's supposed to be private, then reverting the change would make sense. Cheers, Phil. P.S. Oh ARSE! -- of course I just failed to hit R again! and so had to do some more sodding about to actually get the list included in the To: Actually, instead of either of these options, how about some way of letting r do the single reply, and then once inside the reply, having some key binding to add the rest of the recipients in the group, or flip between the two options so one can change one's mind after typing up the reply? -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120628/af6b2439/attachment.pgp>
Re: [PATCH] Restore original keybinding ('r' = reply-to-all)
Jesse Rosenthal writes: ... > If it's not obvious, I'm pretty strongly against Carl's roll-back. I > could, of course, just uncomment my old correction in my .emacs, but I > think it's a change that could hurt users. Those who are more likely to > prefer the reply-all behavior are more likely to be able to change the > defaults. Those who aren't likely to change the defaults are more likely > to be bitten, badly, by a default reply-all behavior. I find the change to the new (only reply to sender) behaviour serously irritating, because it seems I cannot train myself to hit R all the time (which is pretty much what I always want). On the other hand, I'm perfectly capable of customising this, but have something of a fetish for at least trying to live with defaults for a period, so it's my own fault for putting up with it. So, even if I don't personally like it this way round, it is at least fail-safe (well except for the fact that I keep failing to group-reply and then wonder why nobody talks to me any more ;-) Of course, if it turns out that the vast majority of actual users are like me and would prefer to do r and then edit the To/Cc if it's supposed to be private, then reverting the change would make sense. Cheers, Phil. P.S. Oh ARSE! -- of course I just failed to hit R again! and so had to do some more sodding about to actually get the list included in the To: Actually, instead of either of these options, how about some way of letting r do the single reply, and then once inside the reply, having some key binding to add the rest of the recipients in the group, or flip between the two options so one can change one's mind after typing up the reply? -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpYzIcTleJQj.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Patch review/application process
On Tue, 25 Oct 2011 22:42:33 +0200, Daniel Schoepe wrote: ... > - (Re)try some patch/issue management software: Since patches are easily > forgotten if they just float around in several months old mails, it > might be prudent to use something to keep track of patches or issues > these patches address. I know that the patchwork instance didn't work > out so well, partly because it didn't recognize new versions of sent > patches. An alternative might be an issue-based system, which would be > comfortably usable if it supported discussing issues via mail instead > of having to use some web interface. I think this is supported by > redmine. Since the wiki is ikiwiki, it might be worth using the bug tracking available in ikiwiki: http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/ or just create a dedicated instance of ikiwiki just for tracking bugs (possibly as part of the source repository, so that bugs get carried around with the source in git, and can be closed with the commit that fixes them, etc.) Cheers, Phil -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/2002/cffdc1f9/attachment.pgp>
Re: Patch review/application process
On Tue, 25 Oct 2011 22:42:33 +0200, Daniel Schoepe wrote: ... > - (Re)try some patch/issue management software: Since patches are easily > forgotten if they just float around in several months old mails, it > might be prudent to use something to keep track of patches or issues > these patches address. I know that the patchwork instance didn't work > out so well, partly because it didn't recognize new versions of sent > patches. An alternative might be an issue-based system, which would be > comfortably usable if it supported discussing issues via mail instead > of having to use some web interface. I think this is supported by > redmine. Since the wiki is ikiwiki, it might be worth using the bug tracking available in ikiwiki: http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/ or just create a dedicated instance of ikiwiki just for tracking bugs (possibly as part of the source repository, so that bugs get carried around with the source in git, and can be closed with the commit that fixes them, etc.) Cheers, Phil -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgp4uG7weAJ65.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[GNU EMACS] smtpmail package and queue
On Wed, 1 Dec 2010 03:01:47 +0100, first last wrote: > msmtp includes (at last in some distros I think) a script that enqeues mails > when you are offline and sends them when you are online. It is a drop-in > replacement for sendmail. masqmail has this functionality built in, and can be configured to notice the internet connection going up and down, and kick the queue as you go online (although for some reason I cannot persuade it that my OpenVPN is online, even when it is, so have kludged it with cron kicking the queue regularly) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101201/49a6e14d/attachment.pgp>
Re: [GNU EMACS] smtpmail package and queue
On Wed, 1 Dec 2010 03:01:47 +0100, first last wrote: > msmtp includes (at last in some distros I think) a script that enqeues mails > when you are offline and sends them when you are online. It is a drop-in > replacement for sendmail. masqmail has this functionality built in, and can be configured to notice the internet connection going up and down, and kick the queue as you go online (although for some reason I cannot persuade it that my OpenVPN is online, even when it is, so have kludged it with cron kicking the queue regularly) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpmsIksR4VsO.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch