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).

Re: 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).

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

Re: 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.


pgpOt4bxk6pSj.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 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: 

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

Re: 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@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

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.


pgp5zi4sZlKn7.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  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: 

Re: 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-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

Re: 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-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

Re: 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).

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.
bump debian standards version
Increment library version to 1.4.0
Increment notmuch version to 0.6
debian: update list of symbols for libnotmuch
debian: separate build dependency entries on to separate lines
debian: update changelog for 0.6

That's mostly just the release bookkeeping, which is good---that means
I've been through most of the "meat" of the patches on your branch.

I'll now work through what I still have in my queue (Austin's atomicity
work is the only big piece) and then look at the above, at which point
we should be there. (And yes, I know I sound like I'm talking along the
lines of a feature-based release rather than a time-based release.)

-Carl


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

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

Re: 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-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

Re: 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.


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