09/6ef5355de46f3d53db4b55815ea89e20e58c7e

   1 Return-Path: <cworth@cworth.org>\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 961A0431FBD\r
   6         for <notmuch@notmuchmail.org>; Wed,  3 Feb 2010 19:05:51 -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.864\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1.8, AWL=-0.065, BAYES_50=0.001] autolearn=ham\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 lMGzpNF3Y3GP; Wed,  3 Feb 2010 19:05:50 -0800 (PST)\r
  16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  17         by olra.theworths.org (Postfix) with ESMTP id 72806431FAE;\r
  18         Wed,  3 Feb 2010 19:05:50 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id 26629254181; Thu,  4 Feb 2010 16:05:50 +1300 (NZDT)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: martin f krafft <madduck@madduck.net>, notmuch@notmuchmail.org\r
  23 In-Reply-To: <20100125213231.GB15987@lapse.rw.madduck.net>\r
  24 References: <87my083mgh.fsf@SSpaeth.de> <87d4148s2c.fsf@lillypad.riseup.net>\r
  25         <4B595D3A.1030901@SSpaeth.de> <87636u34lw.fsf@SSpaeth.de>\r
  26         <87d411zvz8.fsf@yoom.home.cworth.org>\r
  27         <20100125213231.GB15987@lapse.rw.madduck.net>\r
  28 Date: Wed, 03 Feb 2010 19:05:42 -0800\r
  29 Message-ID: <87ock5punt.fsf@yoom.home.cworth.org>\r
  30 MIME-Version: 1.0\r
  31 Content-Type: multipart/signed; boundary="=-=-=";\r
  32         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  33 Subject: Re: [notmuch] Git feature branch\r
  34 X-BeenThere: notmuch@notmuchmail.org\r
  35 X-Mailman-Version: 2.1.13\r
  36 Precedence: list\r
  37 List-Id: "Use and development of the notmuch mail system."\r
  38         <notmuch.notmuchmail.org>\r
  39 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  40         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  41 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  42 List-Post: <mailto:notmuch@notmuchmail.org>\r
  43 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  44 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  46 X-List-Received-Date: Thu, 04 Feb 2010 03:05:51 -0000\r
  47 \r
  48 --=-=-=\r
  49 Content-Type: text/plain; charset=utf-8\r
  50 Content-Transfer-Encoding: quoted-printable\r
  51 \r
  52 On Tue, 26 Jan 2010 10:32:31 +1300, martin f krafft <madduck@madduck.net> w=\r
  53 rote:\r
  54 > I discussed this with Carl at LCA a bit and ideally we should come\r
  55 > up with a way to relieve Carl of the bottleneck burden (obviously\r
  56 > without stealing away his dictator hat ;)\r
  57 \r
  58 Sounds great! Let's keep working together and find ways to help our\r
  59 community work together. And I really appreciate all the help!\r
  60 \r
  61 > I think it would make sense to move the mainline to git.debian.org\r
  62 > for now, or another place where everyone can easily get an account.\r
  63 > As alternatives I propose repo.or.cz. I'd prefer to stay away from\r
  64 > commercial services like Github.\r
  65 \r
  66 I'm glad to help make things work on notmuchmail.org directly. I don't\r
  67 have a problem giving out shell access to people who want to help set\r
  68 things up the way we want. (And prototyping things elsewhere is fine\r
  69 too.)\r
  70 \r
  71 > Once we're there, how about copying the branch structure from\r
  72 > Git development[0]:\r
  73 >=20\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
  78 \r
  79 I'm not a fan of this scheme, (or maybe I've just never quite understood\r
  80 it).\r
  81 \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
  86 list.\r
  87 \r
  88 Here are some of my thoughts:\r
  89 \r
  90 Instead of "maint" I'd much rather just have branches that are named\r
  91 directly after the stable releases being maintained. We've done this\r
  92 with the cairo repository with branch names like "1.2", "1.4", "1.6",\r
  93 etc. That way it's very clear what the branch represents and it's\r
  94 possible to have multiple concurrent "live" maintenance branches. But of\r
  95 course, until we actually have releases, this doesn't really matter. :-)\r
  96 \r
  97 I want to maintain a branch myself, (where I'm the only person pushing\r
  98 to the branch). [This is different than what I've done with the cairo\r
  99 repository where we have all core maintainer's pushing to a central\r
 100 repository. I'm intentionally trying something new here.]\r
 101 \r
 102 Obviously, that branch that I maintain is currently called "master", but\r
 103 I wouldn't mind (and might actually prefer) to have it be called\r
 104 "~cworth" or so. Though we have the problem that we need "master" to\r
 105 point to *something*.\r
 106 \r
 107 Beyond that, I'm quite happy to have any number of branches similarly\r
 108 maintained by any other individuals. I want to get things setup so that\r
 109 those will be hosted and listed alongside my branch on\r
 110 notmuchmail.org. And I'll be happy to accept pull requests from\r
 111 people. I expect to find people naturally gravitating to "ownership" or\r
 112 particular portions of the code, where I will gain a lot of trust for\r
 113 particular maintainers over the code they own.\r
 114 \r
 115 > What patch tracking workflow should we adopt? Keep sending patches\r
 116 > to the mailing list\r
 117 \r
 118 I definitely like the patches on the list. I find that with notmuch, I\r
 119 can maintain a queue of outstanding patches very effectively, (meaning,\r
 120 that the queue is usable and doesn't forget even if I do get very far\r
 121 behind like I am currently).\r
 122 \r
 123 > master or pu (or even maint/next), as appropriate? Use the Debian\r
 124 > bug tracker? Use Sebastian's Roundup instance? Set up a patch queue\r
 125 > manager on notmuchmail.org? Use patchwork [1]?\r
 126 \r
 127 I'm personally not interested in any system that requires me to push any\r
 128 additional buttons outside of notmuch and git itself. I am interested in\r
 129 tools that can generate reports and help provide visibility into\r
 130 things. So patchwork fixed to automatically notice when patches are\r
 131 merged would be interesting. Also interesting would be support for\r
 132 publishing my notmuch-based queue of patches to a web page.\r
 133 \r
 134 =2DCarl\r
 135 \r
 136 --=-=-=\r
 137 Content-Type: application/pgp-signature\r
 138 \r
 139 -----BEGIN PGP SIGNATURE-----\r
 140 Version: GnuPG v1.4.10 (GNU/Linux)\r
 141 \r
 142 iD8DBQFLajmH6JDdNq8qSWgRAiidAJ4jY7ZpsNbySAMM+6tFj6u/Som2BACgg5CN\r
 143 QRhMik8h8NIBQS51+Wq5slI=\r
 144 =cthl\r
 145 -----END PGP SIGNATURE-----\r
 146 --=-=-=--\r