Re: Bug in emacs showing long threads
[notmuch-archives.git] / a0 / 331877fa053c4c9f0aa113702524eb76404030
1 Return-Path: <jrollins@finestructure.net>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id BA0AD431FBD\r
6         for <notmuch@notmuchmail.org>; Wed,  3 Feb 2010 19:58:19 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -1.631\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5\r
12         tests=[AWL=-1.632, BAYES_50=0.001] autolearn=unavailable\r
13 Received: from olra.theworths.org ([127.0.0.1])\r
14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
15         with ESMTP id 72JZycErTH86 for <notmuch@notmuchmail.org>;\r
16         Wed,  3 Feb 2010 19:58:19 -0800 (PST)\r
17 Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7])\r
18         by olra.theworths.org (Postfix) with ESMTP id 7F460431FAE\r
19         for <notmuch@notmuchmail.org>; Wed,  3 Feb 2010 19:58:19 -0800 (PST)\r
20 Received: from servo.finestructure.net (cpe-72-227-128-66.nyc.res.rr.com\r
21         [72.227.128.66])\r
22         (user=jgr2110 author=jrollins@finestructure.net mech=PLAIN bits=0)\r
23         by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o143w96F019979\r
24         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
25         Wed, 3 Feb 2010 22:58:10 -0500 (EST)\r
26 Received: from jrollins by servo.finestructure.net with local (Exim 4.71)\r
27         (envelope-from <jrollins@finestructure.net>)\r
28         id 1Ncsr3-0004Wx-NF; Wed, 03 Feb 2010 22:58:09 -0500\r
29 From: Jameson Rollins <jrollins@finestructure.net>\r
30 To: Carl Worth <cworth@cworth.org>, martin f krafft <madduck@madduck.net>,\r
31         notmuch@notmuchmail.org\r
32 In-Reply-To: <87ock5punt.fsf@yoom.home.cworth.org>\r
33 References: <87my083mgh.fsf@SSpaeth.de> <87d4148s2c.fsf@lillypad.riseup.net>\r
34         <4B595D3A.1030901@SSpaeth.de> <87636u34lw.fsf@SSpaeth.de>\r
35         <87d411zvz8.fsf@yoom.home.cworth.org>\r
36         <20100125213231.GB15987@lapse.rw.madduck.net>\r
37         <87ock5punt.fsf@yoom.home.cworth.org>\r
38 Date: Wed, 03 Feb 2010 22:58:05 -0500\r
39 Message-ID: <87eil1bqk2.fsf@servo.finestructure.net>\r
40 MIME-Version: 1.0\r
41 Content-Type: multipart/signed; boundary="=-=-=";\r
42         micalg=pgp-sha256; protocol="application/pgp-signature"\r
43 X-No-Spam-Score: Local\r
44 X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7\r
45 Subject: Re: [notmuch] Git feature branch\r
46 X-BeenThere: notmuch@notmuchmail.org\r
47 X-Mailman-Version: 2.1.13\r
48 Precedence: list\r
49 List-Id: "Use and development of the notmuch mail system."\r
50         <notmuch.notmuchmail.org>\r
51 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
52         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
53 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
54 List-Post: <mailto:notmuch@notmuchmail.org>\r
55 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
56 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
57         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
58 X-List-Received-Date: Thu, 04 Feb 2010 03:58:19 -0000\r
59 \r
60 --=-=-=\r
61 \r
62 On Wed, 03 Feb 2010 19:05:42 -0800, Carl Worth <cworth@cworth.org> wrote:\r
63 > I want to maintain a branch myself, (where I'm the only person pushing\r
64 > to the branch). [This is different than what I've done with the cairo\r
65 > repository where we have all core maintainer's pushing to a central\r
66 > repository. I'm intentionally trying something new here.]\r
67 \r
68 Just my 2 cents here, but I fully support the idea of perusing a fully\r
69 distributed development model.  I have been using it on other projects I\r
70 work on and it works great.\r
71 \r
72 > Obviously, that branch that I maintain is currently called "master", but\r
73 > I wouldn't mind (and might actually prefer) to have it be called\r
74 > "~cworth" or so. Though we have the problem that we need "master" to\r
75 > point to *something*.\r
76 \r
77 There's really no need to do that.  For others developers, they would\r
78 just add your repo as a "remote", which would presumably be named\r
79 something like "cworth".  Then in the developers repo your master branch\r
80 would be named "cworth/master".\r
81 \r
82 With a crew of developers, A, B, C, etc., each one would add the others\r
83 as remotes, and their branches would be visible under their remotes, ie:\r
84 \r
85 C@host:~$ git branch -a\r
86 master\r
87 foo\r
88 bar\r
89 remotes/A/master\r
90 remotes/A/foo\r
91 remotes/B/master\r
92 remotes/B/foo\r
93 ...\r
94 \r
95 > Beyond that, I'm quite happy to have any number of branches similarly\r
96 > maintained by any other individuals. I want to get things setup so that\r
97 > those will be hosted and listed alongside my branch on\r
98 > notmuchmail.org. And I'll be happy to accept pull requests from\r
99 > people. I expect to find people naturally gravitating to "ownership" or\r
100 > particular portions of the code, where I will gain a lot of trust for\r
101 > particular maintainers over the code they own.\r
102 \r
103 I think this is the right idea.\r
104 \r
105 I think the problem we've been having recently is that we have bit of a\r
106 patch backlog due to circumstances of Carl's travel.  This is an issue\r
107 because the project is new and people are eager to see their\r
108 contributions in place.  I'm sure Carl will get to them as fast as he\r
109 can.  Once the project becomes more mature and other developers are\r
110 vetting patches, then their branches can take over as "master" in the\r
111 absence of an outdated canonical master.\r
112 \r
113 jamie.\r
114 \r
115 --=-=-=\r
116 Content-Type: application/pgp-signature\r
117 \r
118 -----BEGIN PGP SIGNATURE-----\r
119 Version: GnuPG v1.4.10 (GNU/Linux)\r
120 \r
121 iQIcBAEBCAAGBQJLakXOAAoJEO00zqvie6q8iEQP/3SSva8Ko4fYW1WCFsvMVr8B\r
122 wh/hQWIoXZRCTg+Vr9A4qlIul3qcF88eXGozdtJ9EcS5lu8eVPBF3n/3fYtisjAY\r
123 PFquJ2K8ukTPPoB4SAUOU7lPX6Zc+AjccmHs2kTpe/b6xqRRhYWfjhIJOnbyxeCm\r
124 lt/9CcZ3JHUqh0aCbClRQwAeEVJMIxemQ+khnJDCZDZAlTk+4Yz7HfifRcfFw899\r
125 uYHbiHEt/E45VdmACOAzOZOes46SgDo1x7gqxfuTJ6oOaPWl39XH/YW0nJlHjopp\r
126 ZcawB2EicfKoDBLijTQa+wA28YL0BjL4MfaEFQvjGov60ugaHeYDQw7YA75GBN7h\r
127 a+vwSRxyFC3o+AP8h6YwWxeDUv9lxWCSbJ1mXDVWQSz1Iw7R7I7URUe5PCfgsd/c\r
128 zd8f/Ung9ZLT8rwaRjDr/miY6ycZwDXUxcsZ+naXXZTQvqunPq4wpoQiW6LVTuM4\r
129 /+bFQ/8DVoJhCUAcRn4ngeg2mRpknOxZ6oQviU06ReOmvKl5scuGElu/RVAe+nz7\r
130 e2y4PrjAFiIuj+XK+3yPkBmk1XoqFNDPjFu0voI4ik6KyzgqXMqEHqncrGFE5BVE\r
131 qeY46Lqj0OzUWu2UeA5LR7oafG8GkFQcu4cok5bYRLSayrOlfxJJWqcP0UmOPRHJ\r
132 odLBGU7UApYbpHecxZdi\r
133 =OGqb\r
134 -----END PGP SIGNATURE-----\r
135 --=-=-=--\r