notmuchsync: handling of the deleted tag
Sebastian Spaeth writes: > On 2010-09-21, Rob Browning wrote: >> Conceptually what I'd like for it to do, is reference count -- only mark >> the message deleted if every occurrence (across all maildirs) is marked >> trashed (T). > > Right, but that is trickier than might appear at first sight. In general, I think that until/unless notmuchsync can be more assured of doing the right thing, and in particular, if the deleted tag is likely to become official, notmuchsync should default to not setting it. ...or at least, I'd prefer that. Then I can add --tag-deleted if/when I want to. Of course defaulting to --tag-deleted would also be OK, as long as there's a --no-tag-deleted. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: notmuchsync: handling of the deleted tag
Sebastian Spaeth writes: > On 2010-09-21, Rob Browning wrote: >> Conceptually what I'd like for it to do, is reference count -- only mark >> the message deleted if every occurrence (across all maildirs) is marked >> trashed (T). > > Right, but that is trickier than might appear at first sight. In general, I think that until/unless notmuchsync can be more assured of doing the right thing, and in particular, if the deleted tag is likely to become official, notmuchsync should default to not setting it. ...or at least, I'd prefer that. Then I can add --tag-deleted if/when I want to. Of course defaulting to --tag-deleted would also be OK, as long as there's a --no-tag-deleted. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch development
On Tue, 21 Sep 2010 13:32:30 -0700, Carl Worth wrote: > Also, if anyone has any suggestions for things that we could do to > improve things if I have to "disappear" again in the future, then I > would be happy to do what I can. Hey, Carl. The most obvious thing I can think of is delegating some lieutenants to handle processing patches. There definitely are some worthy candidates (who are kind of already doing this already). Even if they're not actually pushing patches into a canonical repo, they could at least vet in-coming patches and prep things for your review. If they could present you with branches that are potentially "ready to go" it might make things a lot easier for you, especially when you're in a crunch. jamie. -- 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/20100921/cdb3e2fa/attachment.pgp>
Re: notmuch development
On Tue, 21 Sep 2010 17:05:12 -0400, Jameson Rollins wrote: > Hey, Carl. The most obvious thing I can think of is delegating some > lieutenants to handle processing patches. There definitely are some > worthy candidates (who are kind of already doing this already). Even if > they're not actually pushing patches into a canonical repo, they could > at least vet in-coming patches and prep things for your review. If they > could present you with branches that are potentially "ready to go" it > might make things a lot easier for you, especially when you're in a > crunch. Yes. Other people can definitely help me, particular as I gain trust in their ability to review, accept, and reject patches in a similar way to what I would have done myself. I do like that patches are in general sent to the mailing list, and I'd like that to continue. I use searches based on the list messages to determine patches that I still need to review, (though, obviously I'm quite a ways behind in this process). As people review and accept patches, I'd love to receive mail addressed specifically to me, (can copy the list as well, of course), with pointers to git repositories that have "accepted" patches integrated into them. That will definitely help me prioritize pulling such patches into the canonical repository. -Carl -- carl.d.wo...@intel.com pgp7EQIG7dpFt.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch development
On Tue, 21 Sep 2010 17:05:12 -0400, Jameson Rollins wrote: > Hey, Carl. The most obvious thing I can think of is delegating some > lieutenants to handle processing patches. There definitely are some > worthy candidates (who are kind of already doing this already). Even if > they're not actually pushing patches into a canonical repo, they could > at least vet in-coming patches and prep things for your review. If they > could present you with branches that are potentially "ready to go" it > might make things a lot easier for you, especially when you're in a > crunch. Yes. Other people can definitely help me, particular as I gain trust in their ability to review, accept, and reject patches in a similar way to what I would have done myself. I do like that patches are in general sent to the mailing list, and I'd like that to continue. I use searches based on the list messages to determine patches that I still need to review, (though, obviously I'm quite a ways behind in this process). As people review and accept patches, I'd love to receive mail addressed specifically to me, (can copy the list as well, of course), with pointers to git repositories that have "accepted" patches integrated into them. That will definitely help me prioritize pulling such patches into the canonical repository. -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100921/adb2fd80/attachment.pgp>
Re: notmuch development
On Tue, 21 Sep 2010 13:32:30 -0700, Carl Worth wrote: > Also, if anyone has any suggestions for things that we could do to > improve things if I have to "disappear" again in the future, then I > would be happy to do what I can. Hey, Carl. The most obvious thing I can think of is delegating some lieutenants to handle processing patches. There definitely are some worthy candidates (who are kind of already doing this already). Even if they're not actually pushing patches into a canonical repo, they could at least vet in-coming patches and prep things for your review. If they could present you with branches that are potentially "ready to go" it might make things a lot easier for you, especially when you're in a crunch. jamie. pgpAVF4ACVmpG.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: make install tries, fails to install 'test/libnotmuch.so.1.1.0'
On Tue, 21 Sep 2010 11:29:18 -0400, Mike Kelly wrote: > Current master seems to fail to install properly: > > $ make DESTDIR=`readlink -f dest` install ... > install -m0644 test/libnotmuch.so.1.1.0 > /home/pioto/git/notmuch/dest/usr/lib64/ > install: cannot stat `test/libnotmuch.so.1.1.0': No such file or directory > make: *** [install-lib] Error 1 Thanks for the report, Mike. I'd just noticed this myself and pushed out a fix for it. Let me know if you're still encountering any problems after the below commit. -Carl commit 8071c5cd643f7436fb65d0c74676179ea472b155 Author: Carl Worth Date: Tue Sep 21 09:09:01 2010 -0700 lib: Fix "make install" This has been broken since the addition of the test sub-directory to our non-recursive make system. pgp0qCNEf5Bzr.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
make install tries, fails to install 'test/libnotmuch.so.1.1.0'
On Tue, 21 Sep 2010 11:29:18 -0400, Mike Kelly wrote: > Current master seems to fail to install properly: > > $ make DESTDIR=`readlink -f dest` install ... > install -m0644 test/libnotmuch.so.1.1.0 > /home/pioto/git/notmuch/dest/usr/lib64/ > install: cannot stat `test/libnotmuch.so.1.1.0': No such file or directory > make: *** [install-lib] Error 1 Thanks for the report, Mike. I'd just noticed this myself and pushed out a fix for it. Let me know if you're still encountering any problems after the below commit. -Carl commit 8071c5cd643f7436fb65d0c74676179ea472b155 Author: Carl Worth Date: Tue Sep 21 09:09:01 2010 -0700 lib: Fix "make install" This has been broken since the addition of the test sub-directory to our non-recursive make system. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100921/d1c45125/attachment.pgp>
Re: notmuch development
On Tue, 21 Sep 2010 11:38:46 -0400, Scott Henson wrote: > It seems to me that development on notmuch has slowed down recently? Lots > of patches sitting in the patch queue and not much movement on the git > repository? Am I missing where the development is going on? Yes. The git repository has been almost entirely stagnant for the last several months. That was due to me not finding the chance to do notmuch development on a regular basis for some months. Fortunately, I've just recently (in the past week) started doing development again, and I'm optimistic that I'll be able to keep this up going forward. Also, if anyone has any suggestions for things that we could do to improve things if I have to "disappear" again in the future, then I would be happy to do what I can. -Carl -- carl.d.wo...@intel.com pgpJtfQkKrbMK.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch development
On Tue, 21 Sep 2010 11:38:46 -0400, Scott Henson wrote: > It seems to me that development on notmuch has slowed down recently? Lots > of patches sitting in the patch queue and not much movement on the git > repository? Am I missing where the development is going on? Yes. The git repository has been almost entirely stagnant for the last several months. That was due to me not finding the chance to do notmuch development on a regular basis for some months. Fortunately, I've just recently (in the past week) started doing development again, and I'm optimistic that I'll be able to keep this up going forward. Also, if anyone has any suggestions for things that we could do to improve things if I have to "disappear" again in the future, then I would be happy to do what I can. -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100921/d9190293/attachment.pgp>
notmuchsync: handling of the deleted tag
On 2010-09-21, Rob Browning wrote: > Conceptually what I'd like for it to do, is reference count -- only mark > the message deleted if every occurrence (across all maildirs) is marked > trashed (T). Right, but that is trickier than might appear at first sight. I parse those file names which notmuch is giving me (by default for mails from the last 30 days, as reparsing ALL your mails every time would be horribly expensive and often unneeded). notmuch is only able to give me one file name (+path) per mail id, so that is what I examine. If that is the one copy that has the mail dir flag "expired/trashed", I tag the message as "deleted". There is little else that notmuchsync can do here. I ask for new messages and their file path and if they are expired mark it as such. I have no way of finding out if there are other mails with the same mail id from notmuch (unless I am very much mistaken). Doing reference counting would require me/notmuchsync to parse ALL your mails by itself and finding out the often horribly mail id from the mail headers myself... something that notmuchsync does not want to get into. See the problem? I could do reference counting if notmuch were able to tell me how many file names/paths are associated with a mail id. > Though even there I can imagine corner cases: imagine that notmuch > doesn't initially see all your maildirs -- perhaps because you're using > a folder filter in offlineimap, and so there are untrashed copies in the > maildirs it hasn't seen yet. Right that would be a problem. But I cannot do reference counting unless notmuch can give me the number of copies it knows about for a given mail id (and internally it does know all associated file paths, so it would be a simple API extension a la, "get_all_message_file_paths" or similar, or a get_number_of_mail_files(mailid) to start with. > > And what should --revsync do when it finds a mail file that is marked > > as expired. What should notmuch do BTW if there are 2 copies and 1 is expired and 1 not? Mark as "deleted" or not? > Looks like you got cut off there. Right, it was 5pm and I left the computer :). I had intented to rant about the deficiencies of the notmuch 1 document per mail id approach here, but I don't see a better approach. All that would be useful from the notmuch side is to get all associated filenames with a mail id. sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100921/ee4274c6/attachment.pgp>
notmuch development
It seems to me that development on notmuch has slowed down recently? Lots of patches sitting in the patch queue and not much movement on the git repository? Am I missing where the development is going on? -- Scott Henson -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100921/f5b02235/attachment-0001.htm>
make install tries, fails to install 'test/libnotmuch.so.1.1.0'
Current master seems to fail to install properly: $ make DESTDIR=`readlink -f dest` install install-completion mkdir -p /home/pioto/git/notmuch/dest/etc/bash_completion.d install -m0644 completion/notmuch-completion.bash /home/pioto/git/notmuch/dest/etc/bash_completion.d/notmuch mkdir -p /home/pioto/git/notmuch/dest/usr/share/zsh/functions/Completion/Unix install -m0644 completion/notmuch-completion.zsh /home/pioto/git/notmuch/dest/usr/share/zsh/functions/Completion/Unix/notmuch mkdir -p /home/pioto/git/notmuch/dest/usr/share/emacs/site-lisp install -m0644 emacs/notmuch-lib.el emacs/notmuch.el emacs/notmuch-query.el emacs/notmuch-show.el emacs/notmuch-wash.el emacs/notmuch-hello.el emacs/notmuch-mua.el emacs/notmuch-address.el emacs/notmuch-maildir-fcc.el emacs/notmuch-message.el emacs/coolj.el /home/pioto/git/notmuch/dest/usr/share/emacs/site-lisp install -m0644 emacs/notmuch-lib.elc emacs/notmuch.elc emacs/notmuch-query.elc emacs/notmuch-show.elc emacs/notmuch-wash.elc emacs/notmuch-hello.elc emacs/notmuch-mua.elc emacs/notmuch-address.elc emacs/notmuch-maildir-fcc.elc emacs/notmuch-message.elc emacs/coolj.elc /home/pioto/git/notmuch/dest/usr/share/emacs/site-lisp install -m0644 emacs/notmuch-logo.png /home/pioto/git/notmuch/dest/usr/share/emacs/site-lisp mkdir -p /home/pioto/git/notmuch/dest/usr/lib64/ install -m0644 test/libnotmuch.so.1.1.0 /home/pioto/git/notmuch/dest/usr/lib64/ install: cannot stat `test/libnotmuch.so.1.1.0': No such file or directory make: *** [install-lib] Error 1 -- Mike Kelly
notmuchsync: handling of the deleted tag
On Tue, 21 Sep 2010 09:15:44 -0400, Mike Kelly wrote: > I agree, and such an API would be useful for other things too. For > example, I could probably implement a rudamentary gmail syncer with > that. I may just try to make a patch to do this soon if nobody beats me > to it. I think this is related to the requests that I've made to have access to all versions of duplicate messages as well. jamie. -- 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/20100921/69f809b7/attachment.pgp>
notmuchsync: handling of the deleted tag
On Tue, 21 Sep 2010 11:44:29 +0200 Sebastian Spaeth wrote: > Right that would be a problem. But I cannot do reference counting > unless notmuch can give me the number of copies it knows about for a > given mail id (and internally it does know all associated file paths, > so it would be a simple API extension a la, > "get_all_message_file_paths" or similar, or a > get_number_of_mail_files(mailid) to start with. I agree, and such an API would be useful for other things too. For example, I could probably implement a rudamentary gmail syncer with that. I may just try to make a patch to do this soon if nobody beats me to it. -- Mike Kelly
notmuch development
It seems to me that development on notmuch has slowed down recently? Lots of patches sitting in the patch queue and not much movement on the git repository? Am I missing where the development is going on? -- Scott Henson ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
make install tries, fails to install 'test/libnotmuch.so.1.1.0'
Current master seems to fail to install properly: $ make DESTDIR=`readlink -f dest` install install-completion mkdir -p /home/pioto/git/notmuch/dest/etc/bash_completion.d install -m0644 completion/notmuch-completion.bash /home/pioto/git/notmuch/dest/etc/bash_completion.d/notmuch mkdir -p /home/pioto/git/notmuch/dest/usr/share/zsh/functions/Completion/Unix install -m0644 completion/notmuch-completion.zsh /home/pioto/git/notmuch/dest/usr/share/zsh/functions/Completion/Unix/notmuch mkdir -p /home/pioto/git/notmuch/dest/usr/share/emacs/site-lisp install -m0644 emacs/notmuch-lib.el emacs/notmuch.el emacs/notmuch-query.el emacs/notmuch-show.el emacs/notmuch-wash.el emacs/notmuch-hello.el emacs/notmuch-mua.el emacs/notmuch-address.el emacs/notmuch-maildir-fcc.el emacs/notmuch-message.el emacs/coolj.el /home/pioto/git/notmuch/dest/usr/share/emacs/site-lisp install -m0644 emacs/notmuch-lib.elc emacs/notmuch.elc emacs/notmuch-query.elc emacs/notmuch-show.elc emacs/notmuch-wash.elc emacs/notmuch-hello.elc emacs/notmuch-mua.elc emacs/notmuch-address.elc emacs/notmuch-maildir-fcc.elc emacs/notmuch-message.elc emacs/coolj.elc /home/pioto/git/notmuch/dest/usr/share/emacs/site-lisp install -m0644 emacs/notmuch-logo.png /home/pioto/git/notmuch/dest/usr/share/emacs/site-lisp mkdir -p /home/pioto/git/notmuch/dest/usr/lib64/ install -m0644 test/libnotmuch.so.1.1.0 /home/pioto/git/notmuch/dest/usr/lib64/ install: cannot stat `test/libnotmuch.so.1.1.0': No such file or directory make: *** [install-lib] Error 1 -- Mike Kelly ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuchsync: handling of the deleted tag
On Tue, 21 Sep 2010 09:15:44 -0400, Mike Kelly wrote: > I agree, and such an API would be useful for other things too. For > example, I could probably implement a rudamentary gmail syncer with > that. I may just try to make a patch to do this soon if nobody beats me > to it. I think this is related to the requests that I've made to have access to all versions of duplicate messages as well. jamie. pgppl2aag1iKN.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuchsync: handling of the deleted tag
On Tue, 21 Sep 2010 11:44:29 +0200 Sebastian Spaeth wrote: > Right that would be a problem. But I cannot do reference counting > unless notmuch can give me the number of copies it knows about for a > given mail id (and internally it does know all associated file paths, > so it would be a simple API extension a la, > "get_all_message_file_paths" or similar, or a > get_number_of_mail_files(mailid) to start with. I agree, and such an API would be useful for other things too. For example, I could probably implement a rudamentary gmail syncer with that. I may just try to make a patch to do this soon if nobody beats me to it. -- Mike Kelly ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuchsync: handling of the deleted tag
On 2010-09-21, Rob Browning wrote: > Conceptually what I'd like for it to do, is reference count -- only mark > the message deleted if every occurrence (across all maildirs) is marked > trashed (T). Right, but that is trickier than might appear at first sight. I parse those file names which notmuch is giving me (by default for mails from the last 30 days, as reparsing ALL your mails every time would be horribly expensive and often unneeded). notmuch is only able to give me one file name (+path) per mail id, so that is what I examine. If that is the one copy that has the mail dir flag "expired/trashed", I tag the message as "deleted". There is little else that notmuchsync can do here. I ask for new messages and their file path and if they are expired mark it as such. I have no way of finding out if there are other mails with the same mail id from notmuch (unless I am very much mistaken). Doing reference counting would require me/notmuchsync to parse ALL your mails by itself and finding out the often horribly mail id from the mail headers myself... something that notmuchsync does not want to get into. See the problem? I could do reference counting if notmuch were able to tell me how many file names/paths are associated with a mail id. > Though even there I can imagine corner cases: imagine that notmuch > doesn't initially see all your maildirs -- perhaps because you're using > a folder filter in offlineimap, and so there are untrashed copies in the > maildirs it hasn't seen yet. Right that would be a problem. But I cannot do reference counting unless notmuch can give me the number of copies it knows about for a given mail id (and internally it does know all associated file paths, so it would be a simple API extension a la, "get_all_message_file_paths" or similar, or a get_number_of_mail_files(mailid) to start with. > > And what should --revsync do when it finds a mail file that is marked > > as expired. What should notmuch do BTW if there are 2 copies and 1 is expired and 1 not? Mark as "deleted" or not? > Looks like you got cut off there. Right, it was 5pm and I left the computer :). I had intented to rant about the deficiencies of the notmuch 1 document per mail id approach here, but I don't see a better approach. All that would be useful from the notmuch side is to get all associated filenames with a mail id. sebastian pgpv19pmgIUq4.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
