ea/239c13e6bcc373b238c3788bf0b77795656098

   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 6E8AB431FD0\r
   6         for <notmuch@notmuchmail.org>; Fri,  3 Jun 2011 15:56:56 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.01\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
  12         tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled\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 XOOhzPlVHq24 for <notmuch@notmuchmail.org>;\r
  16         Fri,  3 Jun 2011 15:56:56 -0700 (PDT)\r
  17 Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2])\r
  18         by olra.theworths.org (Postfix) with ESMTP id DE5D2431FB6\r
  19         for <notmuch@notmuchmail.org>; Fri,  3 Jun 2011 15:56:55 -0700 (PDT)\r
  20 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  21         by arlo.cworth.org (Postfix) with ESMTP id B20DC29A5CC;\r
  22         Fri,  3 Jun 2011 15:56:54 -0700 (PDT)\r
  23 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  24         id A122625417E; Fri,  3 Jun 2011 15:56:54 -0700 (PDT)\r
  25 From: Carl Worth <cworth@cworth.org>\r
  26 To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
  27         Notmuch Mail <notmuch@notmuchmail.org>\r
  28 Subject: When will we have our next release?\r
  29 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1\r
  30         (i486-pc-linux-gnu)\r
  31 Date: Fri, 03 Jun 2011 15:56:42 -0700\r
  32 Message-ID: <878vtile1h.fsf@yoom.home.cworth.org>\r
  33 MIME-Version: 1.0\r
  34 Content-Type: multipart/signed; boundary="=-=-=";\r
  35         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  36 X-BeenThere: notmuch@notmuchmail.org\r
  37 X-Mailman-Version: 2.1.13\r
  38 Precedence: list\r
  39 List-Id: "Use and development of the notmuch mail system."\r
  40         <notmuch.notmuchmail.org>\r
  41 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  42         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  43 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  44 List-Post: <mailto:notmuch@notmuchmail.org>\r
  45 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  46 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  48 X-List-Received-Date: Fri, 03 Jun 2011 22:56:56 -0000\r
  49 \r
  50 --=-=-=\r
  51 Content-Transfer-Encoding: quoted-printable\r
  52 \r
  53 On Fri, 03 Jun 2011 14:39:13 -0700, Jameson Graef Rollins <jrollins@finestr=\r
  54 ucture.net> wrote:\r
  55 > Can we set a target date for 0.6 release?  So we'll all start feeling\r
  56 > really bad if we miss it?\r
  57 \r
  58 Frankly, I wouldn't mind doing strict time-based releases with something\r
  59 like the following:\r
  60 \r
  61         * We schedule a release period (once per month?)\r
  62 \r
  63         * We schedule a "safety period" before the release (one week?)\r
  64 \r
  65         * At the beginning of the safety period, package up the head\r
  66           of the notmuch tree and upload to Debian experimental and\r
  67           anywhere else similar.\r
  68 \r
  69         * During the safety period we hopefully get wider testing than\r
  70           we normally have from just the git master branch.\r
  71 \r
  72           If any bugs are found and fixed during this time we can create\r
  73           a branch for them. New feature work can continue to land on\r
  74           master.\r
  75 \r
  76         * At the end of the safety period we package up the same bits,\r
  77           or the new bits from the cherry-picked fixes on the branch,\r
  78           and upload them to Debian unstable and anywhere else similar.\r
  79 \r
  80 I'd even be happy for someone else (other than me) to run that process.\r
  81 \r
  82 That might be beneficial for a couple of reasons:\r
  83 \r
  84         * It would simply take one thing off my plate.\r
  85 \r
  86         * I'm inclined to do feature work myself---and when I start\r
  87           doing that again, I might get tempted to delay the release\r
  88           "just until I finish this next feature...".\r
  89 \r
  90 I think that's the problematic state we've been in for the past several\r
  91 months. Right after 0.5 I thought "I should do some database changes to\r
  92 support indexing/searching of arbitrary headers and to capture complete\r
  93 email addresses". I've not actually gotten around to doing that work\r
  94 yet, but I was a bit stuck mentally in "the next release will have those\r
  95 features" so there was never any threat of a release actually happening.\r
  96 \r
  97 So switching to a more strictly time-based cycle can definitely help,\r
  98 (so many other projects use time-based releases very successfully).\r
  99 \r
 100 Now, in order to hand the release process over to someone else, we need\r
 101 a really simple "just push this button" mechanism for the release. I\r
 102 think we've got that pretty-well in place right now, with the large\r
 103 exception of writing the NEWS file.\r
 104 \r
 105 So the fix for that is to start rejecting patches that add features or\r
 106 fix user-visible bugs (other than regressions since the past release)\r
 107 without also updating the NEWS file. I'll commit myself to doing that\r
 108 for my own bug fixes and features as well.\r
 109 \r
 110 I also think it's possible for me to be successful as the release\r
 111 manager as long as we decide on a schedule as a community and that way\r
 112 you all keep me to it.\r
 113 \r
 114 The current state of keep-coding-until-we-have-a-state-good-enough-to-\r
 115 call-the-next-release does have the potential to keep running on\r
 116 forever.\r
 117 \r
 118 I'd be glad to get any feedback or additional ideas from anyone,\r
 119 \r
 120 =2DCarl\r
 121 \r
 122 =2D-=20\r
 123 carl.d.worth@intel.com\r
 124 \r
 125 --=-=-=\r
 126 Content-Type: application/pgp-signature\r
 127 \r
 128 -----BEGIN PGP SIGNATURE-----\r
 129 Version: GnuPG v1.4.11 (GNU/Linux)\r
 130 \r
 131 iEYEARECAAYFAk3pZqoACgkQ6JDdNq8qSWjlxwCfaiEidB5GAQTQp0Q2IUOt7uOO\r
 132 PWwAn2GDT0OEDezEWpR/exx4POLw34BU\r
 133 =4QdX\r
 134 -----END PGP SIGNATURE-----\r
 135 --=-=-=--\r