1 Return-Path: <madduck@lapse.rw.madduck.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 1678D431FBD
\r
6 for <notmuch@notmuchmail.org>; Wed, 3 Feb 2010 19:51:32 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=1.604,
\r
12 BAYES_00=-2.599] 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 2v4WQuPWJkxV for <notmuch@notmuchmail.org>;
\r
16 Wed, 3 Feb 2010 19:51:31 -0800 (PST)
\r
17 Received: from clegg.madduck.net (clegg.madduck.net [193.242.105.96])
\r
18 by olra.theworths.org (Postfix) with ESMTP id 8DF10431FAE
\r
19 for <notmuch@notmuchmail.org>; Wed, 3 Feb 2010 19:51:31 -0800 (PST)
\r
20 Received: from lapse.rw.madduck.net (lapse.nz.madduck.net
\r
21 [IPv6:2001:4428:234::1])
\r
22 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
\r
23 (Client CN "lapse.rw.madduck.net",
\r
24 Issuer "CAcert Class 3 Root" (verified OK))
\r
25 by clegg.madduck.net (postfix) with ESMTPS id 353F81D4099;
\r
26 Thu, 4 Feb 2010 04:50:29 +0100 (CET)
\r
27 Received: by lapse.rw.madduck.net (Postfix, from userid 1000)
\r
28 id D9B2C2A5; Thu, 4 Feb 2010 16:50:26 +1300 (NZDT)
\r
29 Date: Thu, 4 Feb 2010 16:50:26 +1300
\r
30 From: martin f krafft <madduck@madduck.net>
\r
31 To: Carl Worth <cworth@cworth.org>
\r
32 Message-ID: <20100204035026.GA13411@lapse.rw.madduck.net>
\r
33 Mail-Followup-To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org
\r
34 References: <87my083mgh.fsf@SSpaeth.de> <87d4148s2c.fsf@lillypad.riseup.net>
\r
35 <4B595D3A.1030901@SSpaeth.de> <87636u34lw.fsf@SSpaeth.de>
\r
36 <87d411zvz8.fsf@yoom.home.cworth.org>
\r
37 <20100125213231.GB15987@lapse.rw.madduck.net>
\r
38 <87ock5punt.fsf@yoom.home.cworth.org>
\r
40 Content-Type: multipart/signed; micalg=pgp-ripemd160;
\r
41 protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR"
\r
42 Content-Disposition: inline
\r
43 In-Reply-To: <87ock5punt.fsf@yoom.home.cworth.org>
\r
44 X-Motto: Keep the good times rollin'
\r
45 X-OS: Debian GNU/Linux squeeze/sid kernel 2.6.32-trunk-686 i686
\r
46 X-Spamtrap: madduck.bogus@madduck.net
\r
47 X-Subliminal-Message: debian/rules!
\r
48 User-Agent: Mutt/1.5.20 (2009-06-14)
\r
49 X-Virus-Scanned: clamav-milter 0.95.3 at clegg
\r
50 X-Virus-Status: Clean
\r
51 Cc: notmuch@notmuchmail.org
\r
52 Subject: Re: [notmuch] Git feature branch
\r
53 X-BeenThere: notmuch@notmuchmail.org
\r
54 X-Mailman-Version: 2.1.13
\r
56 List-Id: "Use and development of the notmuch mail system."
\r
57 <notmuch.notmuchmail.org>
\r
58 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
59 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
60 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
61 List-Post: <mailto:notmuch@notmuchmail.org>
\r
62 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
63 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
64 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
65 X-List-Received-Date: Thu, 04 Feb 2010 03:51:32 -0000
\r
69 Content-Type: text/plain; charset=utf-8
\r
70 Content-Disposition: inline
\r
71 Content-Transfer-Encoding: quoted-printable
\r
73 also sprach Carl Worth <cworth@cworth.org> [2010.02.04.1605 +1300]:
\r
74 > > maint/ =E2=80=94 the stable release
\r
75 > > master/ =E2=80=94 the stablising head
\r
76 > > next/ =E2=80=94 testing branch
\r
77 > > pu/ =E2=80=94 patch integration branch (proposed updates)
\r
79 > I'm not a fan of this scheme, (or maybe I've just never quite understood
\r
82 > When I first encountered this scheme, (when first using git), it was
\r
83 > never clear to me what branch I should actually run or test as a
\r
84 > user. Nor was it obvious which branches would be regularly rebased or
\r
85 > not---nor which branches had features being discussed on the mailing
\r
88 I'll happily explain if you want. I think that this workflow, in
\r
89 combination with the distributed functionality of Git, makes for
\r
90 really powerful collaboration.
\r
92 To answer your two (implicit) questions directly:
\r
94 - as a user, you'd probably be tracking master, if you aren't
\r
95 running a stable release anyway. if you are ready to deal with the
\r
96 occasional bug and want some juicy stuff, go with next. if you are
\r
97 a developer ready to fend of the sh*t as it hits the fan, use pu.
\r
99 Basically, it's a bit like Debian testing/unstable/experiemental,
\r
100 except that the default entry point for new patches (packages in
\r
101 that analogy) is pu (experimental), not next (unstable, as it is
\r
104 maint is then the stable branch, see below.
\r
106 - nothing is ever rebased. patches are cherry-picked downwards
\r
107 (pu=E2=86=92next=E2=86=92master) and branches are occasionally merged upw=
\r
109 (master into next, next into pu).
\r
111 I don't think we will need 'next' anytime soon, not until we have
\r
112 a situation where we are e.g. working on the next 1.x release by
\r
113 already have 2.0 on the horizon.
\r
115 The important distinction is between pu (proposed-updates) and
\r
116 master. The goal for master should always be that it's usable.
\r
117 Features that are too new to ensure that go to pu until they
\r
120 > Instead of "maint" I'd much rather just have branches that are
\r
121 > named directly after the stable releases being maintained. We've
\r
122 > done this with the cairo repository with branch names like "1.2",
\r
123 > "1.4", "1.6", etc. That way it's very clear what the branch
\r
124 > represents and it's possible to have multiple concurrent "live"
\r
125 > maintenance branches. But of course, until we actually have
\r
126 > releases, this doesn't really matter. :-)
\r
128 This is all possible to do. It has no impact on the pu/next/master
\r
129 distinction. Basically, once a release is made, master is merged
\r
130 into maint (I think) and tagged. If a maintenance release has to be
\r
131 made, a maint/1.0 branch is created. I don't think Git/Linux do
\r
134 > I want to maintain a branch myself, (where I'm the only person
\r
135 > pushing to the branch). [This is different than what I've done
\r
136 > with the cairo repository where we have all core maintainer's
\r
137 > pushing to a central repository. I'm intentionally trying
\r
138 > something new here.]
\r
140 Do you want to maintain that branch yourself for your own purposes,
\r
141 or do you want to be the sole maintainer of the branch that is
\r
142 advertised as *the* notmuch branch, and from which future releases
\r
145 > Obviously, that branch that I maintain is currently called
\r
146 > "master", but I wouldn't mind (and might actually prefer) to have
\r
147 > it be called "~cworth" or so. Though we have the problem that we
\r
148 > need "master" to point to *something*.
\r
150 Actually, there is no reason for master to exist at all. ;)
\r
151 It's just the default, but it's not intrinsic.
\r
153 > Beyond that, I'm quite happy to have any number of branches similarly
\r
154 > maintained by any other individuals. I want to get things setup so that
\r
155 > those will be hosted and listed alongside my branch on
\r
158 So you are talking repos, not branches. I know they are almost the
\r
159 same, but branches live in repos, and if you want to be the only
\r
160 person pushing to a branch, you need to be the only one with write
\r
161 access to the containing repo =E2=80=94 unless you use gitolite, which can
\r
162 do in-repo per-branch access control.
\r
164 > > What patch tracking workflow should we adopt? Keep sending
\r
165 > > patches to the mailing list
\r
167 > I definitely like the patches on the list. I find that with
\r
168 > notmuch, I can maintain a queue of outstanding patches very
\r
169 > effectively, (meaning, that the queue is usable and doesn't forget
\r
170 > even if I do get very far behind like I am currently).
\r
172 The reason why I set up patchwork is because you might have spent
\r
173 hours triaging some patches already, e.g. bringing the count from
\r
174 400 to 100. Since I cannot really "pull" your tags, I am forced to
\r
175 go through the entire list myself.
\r
177 > > master or pu (or even maint/next), as appropriate? Use the
\r
178 > > Debian bug tracker? Use Sebastian's Roundup instance? Set up
\r
179 > > a patch queue manager on notmuchmail.org? Use patchwork [1]?
\r
181 > I'm personally not interested in any system that requires me to
\r
182 > push any additional buttons outside of notmuch and git itself.
\r
183 > I am interested in tools that can generate reports and help
\r
184 > provide visibility into things. So patchwork fixed to
\r
185 > automatically notice when patches are merged would be interesting.
\r
187 Absolutely. There are two comments I have:
\r
189 - this gets easier the closer we get to a centralised model, simply
\r
190 because patchwork is centralised.
\r
192 We *may* be able to use Git's new "notes" feature to attach
\r
193 workflow information to patches, but for that, patches have to
\r
194 become commits in the ancestry, so we need some way of pulling
\r
195 them off the list and into the ancestry.
\r
197 Simply slurping all patches into an 'all-patches' branch won't
\r
198 work due to merge conflicts, so it has to be a manual operation
\r
199 anyway. This then either happens centrally, or we have some sort
\r
200 of communication protocol to tell others which patches have been
\r
201 integrated into the ancestry.
\r
203 This is where patchwork could come in (again).
\r
205 - =E2=80=A6 which brings me to my second point: there are certain things
\r
206 that patchwork can do, at least in theory:
\r
208 * mark patches accepted when they hit your (canonical) master
\r
210 * mark patches rfc when they hit e.g. my (canonical) next branch
\r
211 * mark patches "under review" when they hit the all-patches (or
\r
214 I have not yet tried any of these, and I am basing this theory
\r
215 only on the idea that git-patch-id can come to the rescue, for
\r
216 there is no other linkage between the patch on the mailing list
\r
217 (and thus known to patchwork), and the commit in the repo.
\r
221 * git-patch-id will fail if the patch is modified before it's
\r
222 applied to the ancestry,
\r
223 * git-patch-id might not work at all,
\r
225 * there are status changes that cannot be deduced from Git
\r
226 (rejected, superseded, not applicable, changes requested,
\r
229 we might need some sort of protocol anyway. This could be either
\r
231 * a mail processor, in the style of the Debian bug control system,
\r
232 to which you send commands like 'status 1234 superseded',
\r
234 * a policy specification using e.g. Git notes on commits, such
\r
235 that workflow changes could be attached to commits in a way that
\r
236 would let patchwork and humans follow what's going on.
\r
238 > Also interesting would be support for publishing my notmuch-based
\r
239 > queue of patches to a web page.
\r
241 Absolutely. As I said before, notmuch and tagging could pretty much
\r
242 render patchwork obsolete, but to do that, I /think/ we need to grow
\r
245 - the ability to share tags, so that I don't have to manually track
\r
247 - a web archive with notmuch search/tag support.
\r
249 Simply publishing your workflow statuses would be an improvement,
\r
250 but I am unsure I can fully quantify the gain.
\r
252 In closing, I would like draw a parallel between commits, patches
\r
255 1. notmuch deals with mails, and Git deals with commits
\r
256 2. a commit can be turned into a patch and sent as a mail
\r
257 3. notmuch can tag mails, Git can attach notes to commits
\r
258 4. notes can be used to store tag-like information
\r
260 If we continue the road of sending patches to the mailing list
\r
261 (which I think is a good one, due to discussions and comments), then
\r
262 we inevitably need to link commits to mails, along with the
\r
263 associated metadata (tags, workflow status), in two ways.
\r
268 martin | http://madduck.net/ | http://two.sentenc.es/
\r
270 "of course the music is a great difficulty.
\r
271 you see, if one plays good music, people don't listen,
\r
272 and if one plays bad music people don't talk."
\r
275 spamtraps: madduck.bogus@madduck.net
\r
278 Content-Type: application/pgp-signature; name="digital_signature_gpg.asc"
\r
279 Content-Description: Digital signature (see http://martin-krafft.net/gpg/)
\r
280 Content-Disposition: inline
\r
282 -----BEGIN PGP SIGNATURE-----
\r
283 Version: GnuPG v1.4.10 (GNU/Linux)
\r
285 iEYEAREDAAYFAktqQ/8ACgkQIgvIgzMMSnVjUgCfQ+ol7A/0ui9ZG2GaNgqMeh+9
\r
286 3XgAnR6oVumiHm0ENvGhtCpX41y1zKdk
\r
288 -----END PGP SIGNATURE-----
\r
290 --9jxsPFA5p3P2qPhR--
\r