From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.86.59.13 with SMTP id h13cs12398fga; Sun, 21 Feb 2010 05:30:43 -0800 (PST) Received: by 10.224.106.80 with SMTP id w16mr5031592qao.362.1266759042075; Sun, 21 Feb 2010 05:30:42 -0800 (PST) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id 6si6287554qwd.6.2010.02.21.05.30.41; Sun, 21 Feb 2010 05:30:42 -0800 (PST) Received-SPF: pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-devel-bounces@rubyforge.org Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 7C08C18582EC; Sun, 21 Feb 2010 08:30:41 -0500 (EST) Received: from smtp.mail.drexel.edu (pm2.irt.drexel.edu [144.118.29.82]) by rubyforge.org (Postfix) with ESMTP id AF77518582AC for ; Sun, 21 Feb 2010 08:30:31 -0500 (EST) Received: from smtp.mail.drexel.edu (localhost.localdomain [127.0.0.1]) by smtp.mail.drexel.edu (Postfix) with SMTP id 5B07E116740 for ; Sun, 21 Feb 2010 08:30:31 -0500 (EST) Received: from localhost (c-68-37-236-192.hsd1.nj.comcast.net [68.37.236.192]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mail.drexel.edu (Postfix) with ESMTP id 1CDE4116742 for ; Sun, 21 Feb 2010 08:30:31 -0500 (EST) Date: Sun, 21 Feb 2010 08:42:49 -0500 From: "W. Trevor King" To: Sup developer discussion Message-ID: <20100221134249.GA11429@mjolnir> References: <20100218114943.GB911@mjolnir> <1266730498-sup-78@tilus.net> MIME-Version: 1.0 In-Reply-To: <1266730498-sup-78@tilus.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-PerlMx-Authed: User SMTP Authed Subject: Re: [sup-devel] email threading - tree vs. graph X-BeenThere: sup-devel@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sup developer discussion List-Id: Sup developer discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0887878675==" Sender: sup-devel-bounces@rubyforge.org Errors-To: sup-devel-bounces@rubyforge.org --===============0887878675== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 21, 2010 at 08:38:35AM +0200, Tero Tilus wrote: > > For example, here's a slice from the recent be-devel list as a graph: > > ............... > > | *-|-\ | | Mon Jan 25 W. Trevor King Re: Project releases > > | * | | | | Sat Jan 23 Gianluca Montecchi Re: Project releases > > | | | | t | | Sat Jan 23 Gianluca Montecchi Re: Project releases > > | *-|-|-|-\ | | Fri Jan 22 Ben Finney Re: Project releases > > | | | * | | | | Fri Jan 22 W. Trevor King Re: Project releases > > | | | *-/ | | | Thu Jan 21 Ben Finney Re: Project releases > > | * | | | | | Thu Jan 21 Gianluca Montecchi Re: Project releases > > *-|-|-/ | | | Thu Jan 21 W. Trevor King Re: Project releases > > ............... > > ^--- inheritence graph. > > You can see that Ben's Fri message and my Mon message both have two > > parents. >=20 > Honestly. That took fair bit of staring and prolly wouldn't have > opened to me without your explanation. :) But that might only be due > to the external noise in the graph. Without those extra through-lines > it looks a bit more readable. It's a snip from the full list sorted by date, so there are a bunch of through-lines when threads went out of fasion for a while ;). If you sorted by oldest parent date first, you would probably have fewer. > I can't really see how this would lump significantly more mail into > one thread. Do you have examples of otherwise disconnected trees > connected only by multi-parent mail? *-\-\-\-\-\-\-\-\ Fri May 16 Chris Ball how to use the git backend? r | | | | | | | | Fri May 16 Christian Garbs how to use the git backend? r-/ | | | | | | | Wed May 14 Jelmer Vernooij [MERGE] Two tiny fixes r---/ | | | | | | Mon Apr 21 Ben Finney [MERGE] Manual page for 'be' co= mmand. *-----/ | | | | | Mon Apr 21 Ben Finney [MERGE] Makefile: add skeleton = 'build' .. r | | | | | Mon Apr 21 Ben Finney [MERGE] Makefile: Add with 'cle= an' targ.. *-------/ | | | | Fri Apr 18 Ben Finney [MERGE] Add bug 00f (now fixed) r | | | | Fri Apr 18 Ben Finney [MERGE] Updated GPLv2 text and = FSF addr.. r---------/ | | | Fri Apr 18 Ben Finney [MERGE] Bugs-Everywhere-Web/lib= be: Fix .. *-----------/ | | Mon Apr 14 j@oil21.org [PATCH] Bugs-Everywhere-Web id= entity r | | Mon Apr 14 j@oil21.org [PATCH] Bugs-Everywhere-Web id= entity r-------------/ | Mon Apr 14 j@oil21.org [MERGE] update about r---------------/ Mon Apr 14 j@oil21.org [MERGE] Bugs-Everywhere-Web wo= rks with . Where Chris' mail was "... I also merged patches from...". Another case that comes up is that a user will post with a problem that's been discussed before, and we reply and link to the previous discussion. These are both software mailing list specific though. I don't have examples from other settings. > > With your thread-centric approach, you'll want to break threads when > > the topic mutates too far from the original, and that could be > > difficult for meshy-graphs. >=20 > Topic-mutation happens within a tree as well. And pruning (boy I've > wanted to do that quite a few times, I notice) afaik essentially > requires scanning (and potentially modifying) all the messages in the > thread. Technically I don't see how this is very different. > "Politically" it however could be. If your mail graph is one big lump > of spaghetti, it might be difficult to decide where to cut it off. ;) My infant be.mailing-list branch (link below) is an attempt to address this by leaving the spaghetti alone, and attaching entry-point tags wherever you feel the subject makes a significant shift. Really, you *want* the spaghetti, since its human-generated cross-linking that reduces duplication-of-search effort. Assuming you trust the human in question ;). > > On an implementation level, I've got the above graph browser going > > in python/curses, so it should be easy to port to ruby/curses. >=20 > Have a pointer to code? My code is currently stuffed into an in-transition BE project, but it should be easy to separate. Grab the whole repo with Bazaar: bzr branch http://www.physics.drexel.edu/~wking/code/bzr/be.mailing-list Graphing module is libbe/util/graph.py. My very minimal browser is misc/mailbox-tools/mailgraph.py. Set up the BE version file with cd be.mailing-list make libbe/_version.py and run the browser with misc/mailbox-tools/mailgraph.py *.mbox Press 'h' for help. The graph module is pretty clean, but the others are not ;). > I would love to see sup being able to do something usefull with > multiple parent messages. If you want to use this in the wild, you'll need to figure out how to integrate multiple-parent In-Reply-To\s with your current JWZ threading which only uses References. From RFC 2822, section 3.6.4: Note: Some implementations parse the "References:" field to display the "thread of the discussion". These implementations assume that each new message is a reply to a single parent and hence that they can walk backwards through the "References:" field to find the parent of each message listed there. Therefore, trying to form a "References:" field for a reply that has multiple parents is discouraged and how to do so is not defined in this document. On major benefit of JWZ-threading is that it's self-healing. If some users don't thread their replies, you can thread them locally and reply, fixing the threading for others recieving your reply. The In-Reply-To alternative is to reply to both the broken message and the original thread: *-\ fixing response | r broken message * original thread which is needlessly uglier than * fixing response * broken message * original thread if it is clear from the content of the broken message that it really was a reply. I think it would be best to leave view-graph and browse-to-other-parent as peripheral options, to be used on curated archives where you can trust In-Reply-To to be RFC 2822 compliant (e.g. the eventual be.mailing-list ;). --=20 This email may be signed or encrypted with GPG (http://www.gnupg.org). The GPG signature (if present) will be attached as 'signature.asc'. For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkuBOFkACgkQY8LZ/us1fmBhJwCdGp8pjuRIy6/8k/78p9RJyhp9 r/0An1g9v2UkvusakObbZr/oha7F6meB =+oK7 -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- --===============0887878675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel --===============0887878675==--