tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins  wrote:
> Did you guys try to address the issue of tag removal at all?  I've been
> trying to decide if this is something we need to worry about or not.
> For instance, if cworth pushed a tag ".needs-review", you would probably
> want to have that tag removed if cworth removed it.  I guess
> alternatively he could just push the tag ".reviewed" to nullify the
> meaning of the previous one.  I'm not sure that would work in all cases,
> though.

Yes, if he deletes the tag "public.needs-review" in his notmuch, and
then pushes it, it will delete the tag "cworth.needs-review" from yours.

A couple points about this:

1. If you added your own "needs-review" tag to things that have a
"cworth.needs-review" tag, that wouldn't be deleted. In other words,
cworth's actions will only affect that namespace. Now, if you delete it,
and push it, and Carl pulls back from you (meaning he trusts you), then
it would be deleted on his. When he pushes next, it will be deleted on
everyone who pulls from him.

I'm sure there are resolution paradoxes here. It only had a ten-minute
trial run one day on IRC with me and someone else.

2. The history is available. If you run `nm-remote history msg-id`, it
will show you its history of being added and deleted. I think it will
show by whom it was added or deleted as well, but I don't quite remember
(I hacked this up over a year ago).

tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal  
wrote:
> After a conversation with David last year about bug-tracking, I worked
> up a rough python-based prototype of this. It worked in terms of
> namespaces, so Carl could associate the namespace "public" with a list
> of tags he publishes to a http-accessable location. And you could
> associate the namespace "cworth" with those same tags.

This sounds very cool, Jesse.  Very git-like.  I like it.

> You type `whatevercommand pull cworth` and the tags come down from that
> URL as "cworth.*".
> 
> So what he has as "public.to-push" comes down to your notmuch as
> "cworth.to-push".

Did you guys try to address the issue of tag removal at all?  I've been
trying to decide if this is something we need to worry about or not.
For instance, if cworth pushed a tag ".needs-review", you would probably
want to have that tag removed if cworth removed it.  I guess
alternatively he could just push the tag ".reviewed" to nullify the
meaning of the previous one.  I'm not sure that would work in all cases,
though.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 After a conversation with David last year about bug-tracking, I worked
 up a rough python-based prototype of this. It worked in terms of
 namespaces, so Carl could associate the namespace public with a list
 of tags he publishes to a http-accessable location. And you could
 associate the namespace cworth with those same tags.

This sounds very cool, Jesse.  Very git-like.  I like it.

 You type `whatevercommand pull cworth` and the tags come down from that
 URL as cworth.*.
 
 So what he has as public.to-push comes down to your notmuch as
 cworth.to-push.

Did you guys try to address the issue of tag removal at all?  I've been
trying to decide if this is something we need to worry about or not.
For instance, if cworth pushed a tag .needs-review, you would probably
want to have that tag removed if cworth removed it.  I guess
alternatively he could just push the tag .reviewed to nullify the
meaning of the previous one.  I'm not sure that would work in all cases,
though.

jamie.


pgpOt4bxk6pSj.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 Did you guys try to address the issue of tag removal at all?  I've been
 trying to decide if this is something we need to worry about or not.
 For instance, if cworth pushed a tag .needs-review, you would probably
 want to have that tag removed if cworth removed it.  I guess
 alternatively he could just push the tag .reviewed to nullify the
 meaning of the previous one.  I'm not sure that would work in all cases,
 though.

Yes, if he deletes the tag public.needs-review in his notmuch, and
then pushes it, it will delete the tag cworth.needs-review from yours.

A couple points about this:

1. If you added your own needs-review tag to things that have a
cworth.needs-review tag, that wouldn't be deleted. In other words,
cworth's actions will only affect that namespace. Now, if you delete it,
and push it, and Carl pulls back from you (meaning he trusts you), then
it would be deleted on his. When he pushes next, it will be deleted on
everyone who pulls from him.

I'm sure there are resolution paradoxes here. It only had a ten-minute
trial run one day on IRC with me and someone else.

2. The history is available. If you run `nm-remote history msg-id`, it
will show you its history of being added and deleted. I think it will
show by whom it was added or deleted as well, but I don't quite remember
(I hacked this up over a year ago).

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Mon, 06 Jun 2011 09:28:13 -0700, Jameson Graef Rollins  wrote:
> I've been thinking about this more and it really seems we need a way to
> just share tags.  What if we had a way to export all the tags for a set
> of messages as a notmuch dump file, that could just be piped into
> notmuch to modify tags?  This would be a great way for lots of people to
> keep tags synced on a set of messages.

After a conversation with David last year about bug-tracking, I worked
up a rough python-based prototype of this. It worked in terms of
namespaces, so Carl could associate the namespace "public" with a list
of tags he publishes to a http-accessable location. And you could
associate the namespace "cworth" with those same tags.

He types `whatevercommand push public` and all tags "public.*" go to an
config-associated URL.

You type `whatevercommand pull cworth` and the tags come down from that
URL as "cworth.*".

So what he has as "public.to-push" comes down to your notmuch as
"cworth.to-push".

It's available here:

http://commonmeasure.org/~jkr/git/nm-remote.git

See these emails for more (but note that the repo url has changed to the
above).

id:"m1k4rkkchy.fsf at watt.gilman.jhu.edu"
id:"m1hbmokbxj.fsf at watt.gilman.jhu.edu"

There were some details and inherent ambiguities about conflict
resolution, and the above emails explain how I dealt with them. 

Note also that it uses python's configparser, which will overwrite your
config -- which means it'll get rid of your comments. So if you use any
of the config-writing commands, make sure you back up your config first.

Best,
Jesse

tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 05:17:27 -0700, Carl Worth  wrote:
> Hopefully, someone will provide me with a good way to publish my queue
> soon, ("notmuch search --output=html" ?), and then communication like
> this will be a bit easier. ;-)

I've been thinking about this more and it really seems we need a way to
just share tags.  What if we had a way to export all the tags for a set
of messages as a notmuch dump file, that could just be piped into
notmuch to modify tags?  This would be a great way for lots of people to
keep tags synced on a set of messages.

The main difficulty (seems to me) would be the sharing of -tags.  You
wouldn't want the absence of a tag on a message in the tag file to mean
that the tag should be removed.  So we would need to represent both
+tags and -tags in the dump file [0].

It seems a little crazy, but would it be possible to store -tags in the
database somehow?

jamie.

[0] This would actually help with tags applied when the message is
indexed as well, like "signed" and "encrypted", since it would allow for
tagging messages that were indexed before the "signed"/"encrypted"
tagging was a feature.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

release-candidate/0.6 redux

[Carl Worth]

On Sun, 05 Jun 2011 17:35:40 -0700, Jameson Graef Rollins  wrote:
> On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth  wrote:
> > From a quick rebase of your release-candidate branch and a comparison
> > with what I have queued it looks like only the following commits are
> > left on your branch and not in my email queue:
> > 
> > emacs: update notmuch-crypto-process-mime config variable documentation.
> 
> Hey, Carl.  This is actually a five-patch series that starts at:
> 
>  emacs: add notmuch-show-refresh-view function
>   id:"1306627784-3401-1-git-send-email-jrollins at finestructure.net"

OK, good. That is actually part of my queue.

> You should also look at the following two patch series to fix the
> message/rfc822 part handling:
> 
>  Do not attept to output part raw if part is not GMimePart.
>   id:"1307120466-4980-1-git-send-email-jrollins at finestructure.net"
> 
>  improving message/rfc822 part handling
>   id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net"

OK. These are also already queued.

Hopefully, someone will provide me with a good way to publish my queue
soon, ("notmuch search --output=html" ?), and then communication like
this will be a bit easier. ;-)

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: release-candidate/0.6 redux

[Carl Worth]

On Sun, 05 Jun 2011 17:35:40 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth cwo...@cworth.org wrote:
  From a quick rebase of your release-candidate branch and a comparison
  with what I have queued it looks like only the following commits are
  left on your branch and not in my email queue:
  
  emacs: update notmuch-crypto-process-mime config variable documentation.
 
 Hey, Carl.  This is actually a five-patch series that starts at:
 
  emacs: add notmuch-show-refresh-view function
   id:1306627784-3401-1-git-send-email-jroll...@finestructure.net

OK, good. That is actually part of my queue.

 You should also look at the following two patch series to fix the
 message/rfc822 part handling:
 
  Do not attept to output part raw if part is not GMimePart.
   id:1307120466-4980-1-git-send-email-jroll...@finestructure.net
 
  improving message/rfc822 part handling
   id:1307320169-29905-1-git-send-email-jroll...@finestructure.net

OK. These are also already queued.

Hopefully, someone will provide me with a good way to publish my queue
soon, (notmuch search --output=html ?), and then communication like
this will be a bit easier. ;-)

-Carl

-- 
carl.d.wo...@intel.com


pgp97VBjumIaN.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

tag sharing [was: Re: release-candidate/0.6 redux]

[Jameson Graef Rollins]

On Mon, 06 Jun 2011 05:17:27 -0700, Carl Worth cwo...@cworth.org wrote:
 Hopefully, someone will provide me with a good way to publish my queue
 soon, (notmuch search --output=html ?), and then communication like
 this will be a bit easier. ;-)

I've been thinking about this more and it really seems we need a way to
just share tags.  What if we had a way to export all the tags for a set
of messages as a notmuch dump file, that could just be piped into
notmuch to modify tags?  This would be a great way for lots of people to
keep tags synced on a set of messages.

The main difficulty (seems to me) would be the sharing of -tags.  You
wouldn't want the absence of a tag on a message in the tag file to mean
that the tag should be removed.  So we would need to represent both
+tags and -tags in the dump file [0].

It seems a little crazy, but would it be possible to store -tags in the
database somehow?

jamie.

[0] This would actually help with tags applied when the message is
indexed as well, like signed and encrypted, since it would allow for
tagging messages that were indexed before the signed/encrypted
tagging was a feature.


pgp5zi4sZlKn7.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Mon, 06 Jun 2011 09:28:13 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 I've been thinking about this more and it really seems we need a way to
 just share tags.  What if we had a way to export all the tags for a set
 of messages as a notmuch dump file, that could just be piped into
 notmuch to modify tags?  This would be a great way for lots of people to
 keep tags synced on a set of messages.

After a conversation with David last year about bug-tracking, I worked
up a rough python-based prototype of this. It worked in terms of
namespaces, so Carl could associate the namespace public with a list
of tags he publishes to a http-accessable location. And you could
associate the namespace cworth with those same tags.

He types `whatevercommand push public` and all tags public.* go to an
config-associated URL.

You type `whatevercommand pull cworth` and the tags come down from that
URL as cworth.*.

So what he has as public.to-push comes down to your notmuch as
cworth.to-push.

It's available here:

http://commonmeasure.org/~jkr/git/nm-remote.git

See these emails for more (but note that the repo url has changed to the
above).

id:m1k4rkkchy@watt.gilman.jhu.edu
id:m1hbmokbxj@watt.gilman.jhu.edu

There were some details and inherent ambiguities about conflict
resolution, and the above emails explain how I dealt with them. 

Note also that it uses python's configparser, which will overwrite your
config -- which means it'll get rid of your comments. So if you use any
of the config-writing commands, make sure you back up your config first.

Best,
Jesse
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6 redux

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth  wrote:
> From a quick rebase of your release-candidate branch and a comparison
> with what I have queued it looks like only the following commits are
> left on your branch and not in my email queue:
> 
> emacs: update notmuch-crypto-process-mime config variable documentation.

Hey, Carl.  This is actually a five-patch series that starts at:

 emacs: add notmuch-show-refresh-view function
  id:"1306627784-3401-1-git-send-email-jrollins at finestructure.net"

You should also look at the following two patch series to fix the
message/rfc822 part handling:

 Do not attept to output part raw if part is not GMimePart.
  id:"1307120466-4980-1-git-send-email-jrollins at finestructure.net"

 improving message/rfc822 part handling
  id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net"

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: release-candidate/0.6 redux

[Jameson Graef Rollins]

On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth cwo...@cworth.org wrote:
 From a quick rebase of your release-candidate branch and a comparison
 with what I have queued it looks like only the following commits are
 left on your branch and not in my email queue:
 
 emacs: update notmuch-crypto-process-mime config variable documentation.

Hey, Carl.  This is actually a five-patch series that starts at:

 emacs: add notmuch-show-refresh-view function
  id:1306627784-3401-1-git-send-email-jroll...@finestructure.net

You should also look at the following two patch series to fix the
message/rfc822 part handling:

 Do not attept to output part raw if part is not GMimePart.
  id:1307120466-4980-1-git-send-email-jroll...@finestructure.net

 improving message/rfc822 part handling
  id:1307320169-29905-1-git-send-email-jroll...@finestructure.net

jamie.


pgpw9OBIslcuw.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6 redux

[Carl Worth]

On Tue, 31 May 2011 11:43:31 -0700, Jameson Graef Rollins  wrote:
> Hi, folks.  I have pushed a new version of the release-candidate/0.6
> branch to my repo [0].  It is all reworked on top of notmuch/master [1],
> and includes:
...
> cworth: do you want to review this for the new release?  We're very close!
> One last push and we can get this thing out.

I've been going through it, but trying to focus more on the emails I
have queued up (which is currently 58 messages).

release-candidate/0.6 redux

[Jameson Graef Rollins]

Hi, folks.  I have pushed a new version of the release-candidate/0.6
branch to my repo [0].  It is all reworked on top of notmuch/master [1],
and includes:

* the miscellaneous fixes/improvements patch series starting at
  id:"1306619520-25730-2-git-send-email-jrollins at finestructure.net"
* the notmuch-show refresh patches
* Austin's atomicity patches
* Felipe's vim patches
* updates to the debian packaging

cworth: do you want to review this for the new release?  We're very close!
One last push and we can get this thing out.

bremner: do you want to reconcile this with what you've already pushed
to Debian experimental, and then push another version?

jamie.

[0] git://finestructure.net/notmuch [release-candidate/0.6]
[1] cb8418784c21155ffea79cce8409a7ea3c546937
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: release-candidate/0.6 redux

[Jameson Graef Rollins]

Hi, folks.  I have pushed a new version of the release-candidate/0.6
branch to my repo [0].  It is all reworked on top of notmuch/master [1],
and includes:

* the miscellaneous fixes/improvements patch series starting at
  id:1306619520-25730-2-git-send-email-jroll...@finestructure.net
* the notmuch-show refresh patches
* Austin's atomicity patches
* Felipe's vim patches
* updates to the debian packaging

cworth: do you want to review this for the new release?  We're very close!
One last push and we can get this thing out.

bremner: do you want to reconcile this with what you've already pushed
to Debian experimental, and then push another version?

jamie.

[0] git://finestructure.net/notmuch [release-candidate/0.6]
[1] cb8418784c21155ffea79cce8409a7ea3c546937


pgpzTvq91w1OQ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

release-candidate/0.6 redux

[Austin Clements]

On Sat, May 28, 2011 at 5:58 PM, Jameson Graef Rollins
 wrote:
> Austin: speaking of which, would you mind rebasing that patch series
> against notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937 and
> sending that to the list again? ?That might help push Carl to merge that
> stuff sooner. ?I think the conflicts are very minor.

Done.  The only conflicts were the usual suspects (lists in the test
suite).  I pulled in the GDB dependency in the test suite and the
corresponding tweaks to test-lib that were on the list previously
(id:"1305206080-17461-1-git-send-email-amdragon at mit.edu" and
id:"1305206110-17511-1-git-send-email-amdragon at mit.edu").  It's on
for-review/atomic-new-v4 at the usual,
  http://awakening.csail.mit.edu/git/notmuch.git

release-candidate/0.6 redux

[Jameson Graef Rollins]

On Sat, 28 May 2011 14:51:35 -0700, Jameson Graef Rollins  wrote:
> So what follows is a patch series for a bunch of miscellaneous patches
> that should be included in 0.6.  Most of them were originally part of
> the release-candiate/0.6 branch, and they are here rebased on top of
> notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937, which
> includes all the multipart and crypto rework.

I forgot to mention that the other two things that were in the original
release-candidate/0.6 that really need to be included before 0.6 is
released are

* Austin Clements's atomicity patches
* Felipe Contreras's vim patches

both of which have been sent to the list previously, although I believe
that Austin might have a couple extra patches in his atomic-new-v3
branch.

Austin: speaking of which, would you mind rebasing that patch series
against notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937 and
sending that to the list again?  That might help push Carl to merge that
stuff sooner.  I think the conflicts are very minor.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

release-candidate/0.6 redux

[Jameson Graef Rollins]

So what follows is a patch series for a bunch of miscellaneous patches
that should be included in 0.6.  Most of them were originally part of
the release-candiate/0.6 branch, and they are here rebased on top of
notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937, which
includes all the multipart and crypto rework.

Some of these patches are cleanup, but some are important bug fixes,
some previously sent to the list by others that I have signed off on,
and some by me that were not previously sent to the list.  I highly
recommend that this entire series be incorporated before 0.6 is
released.

jamie.

release-candidate/0.6 redux

[Jameson Graef Rollins]

So what follows is a patch series for a bunch of miscellaneous patches
that should be included in 0.6.  Most of them were originally part of
the release-candiate/0.6 branch, and they are here rebased on top of
notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937, which
includes all the multipart and crypto rework.

Some of these patches are cleanup, but some are important bug fixes,
some previously sent to the list by others that I have signed off on,
and some by me that were not previously sent to the list.  I highly
recommend that this entire series be incorporated before 0.6 is
released.

jamie.

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6 redux

[Jameson Graef Rollins]

On Sat, 28 May 2011 14:51:35 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 So what follows is a patch series for a bunch of miscellaneous patches
 that should be included in 0.6.  Most of them were originally part of
 the release-candiate/0.6 branch, and they are here rebased on top of
 notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937, which
 includes all the multipart and crypto rework.

I forgot to mention that the other two things that were in the original
release-candidate/0.6 that really need to be included before 0.6 is
released are

* Austin Clements's atomicity patches
* Felipe Contreras's vim patches

both of which have been sent to the list previously, although I believe
that Austin might have a couple extra patches in his atomic-new-v3
branch.

Austin: speaking of which, would you mind rebasing that patch series
against notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937 and
sending that to the list again?  That might help push Carl to merge that
stuff sooner.  I think the conflicts are very minor.

jamie.


pgpx7fw0osdyJ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: release-candidate/0.6 redux

[Austin Clements]

On Sat, May 28, 2011 at 5:58 PM, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 Austin: speaking of which, would you mind rebasing that patch series
 against notmuch/master at cb8418784c21155ffea79cce8409a7ea3c546937 and
 sending that to the list again?  That might help push Carl to merge that
 stuff sooner.  I think the conflicts are very minor.

Done.  The only conflicts were the usual suspects (lists in the test
suite).  I pulled in the GDB dependency in the test suite and the
corresponding tweaks to test-lib that were on the list previously
(id:1305206080-17461-1-git-send-email-amdra...@mit.edu and
id:1305206110-17511-1-git-send-email-amdra...@mit.edu).  It's on
for-review/atomic-new-v4 at the usual,
  http://awakening.csail.mit.edu/git/notmuch.git
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch