Re: message-default-mail-headers not working in notmuch 0.22
[notmuch-archives.git] / 65 / e835de3aa0d4a81159d8e0a91303576b620356
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 A6C9A4196F0\r
6         for <notmuch@notmuchmail.org>; Wed,  7 Apr 2010 15:27:06 -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: -2.89\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
13         autolearn=ham\r
14 Received: from olra.theworths.org ([127.0.0.1])\r
15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
16         with ESMTP id 3RooWtY0rS7T; Wed,  7 Apr 2010 15:27:05 -0700 (PDT)\r
17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
18         by olra.theworths.org (Postfix) with ESMTP id D632D431FC1;\r
19         Wed,  7 Apr 2010 15:27:05 -0700 (PDT)\r
20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
21         id 9760025400C; Wed,  7 Apr 2010 15:27:05 -0700 (PDT)\r
22 From: Carl Worth <cworth@cworth.org>\r
23 To: Michal Sojka <sojkam1@fel.cvut.cz>, Sebastian Spaeth\r
24         <Sebastian@SSpaeth.de>, notmuch@notmuchmail.org\r
25 Subject: Re: [PATCH] Derive version numbers from git\r
26 In-Reply-To: <87ochw7e8f.fsf@steelpick.2x.cz>\r
27 References: <87hbnpo1yu.fsf@yoom.home.cworth.org>\r
28         <87y6h16lun.fsf@steelpick.2x.cz> <87pr2c7pm1.fsf@SSpaeth.de>\r
29         <87ochw7e8f.fsf@steelpick.2x.cz>\r
30 Date: Wed, 07 Apr 2010 15:27:05 -0700\r
31 Message-ID: <871veqrj9i.fsf@yoom.home.cworth.org>\r
32 MIME-Version: 1.0\r
33 Content-Type: multipart/signed; boundary="=-=-=";\r
34         micalg=pgp-sha1; protocol="application/pgp-signature"\r
35 X-BeenThere: notmuch@notmuchmail.org\r
36 X-Mailman-Version: 2.1.13\r
37 Precedence: list\r
38 List-Id: "Use and development of the notmuch mail system."\r
39         <notmuch.notmuchmail.org>\r
40 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
41         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
42 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
43 List-Post: <mailto:notmuch@notmuchmail.org>\r
44 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
45 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
46         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
47 X-List-Received-Date: Wed, 07 Apr 2010 22:27:06 -0000\r
48 \r
49 --=-=-=\r
50 Content-Transfer-Encoding: quoted-printable\r
51 \r
52 On Tue, 06 Apr 2010 18:11:28 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrot=\r
53 e:\r
54 >  On Tue, 06 Apr 2010, Sebastian Spaeth wrote:\r
55 >\r
56 >  > But, there are people without git installed that download the release\r
57 >  > tarball. So if this patch makes it, we need to replace this with a\r
58 >  > static version number when baking a release tar.\r
59 >=20\r
60 > Right, here is an updated patch. It's more complicated than the previous\r
61 > one, but it solves the issue.\r
62 \r
63 I like this idea, definitely.\r
64 \r
65 But the other piece needed here is a way for me to be able to specify a\r
66 version in order to release. In my current release instructions\r
67 (notmuch/RELEASING) I do that by manually incrementing the version\r
68 number in the Makefile. Then a tag is created later when the "make\r
69 release" target runs.\r
70 \r
71 It would be possible for me to instead create the tag to specify the\r
72 version, but there's a few things I don't like about this:\r
73 \r
74 1. After I increment the version number (early in the release process) I\r
75    often find one or two little things I need to change to make the\r
76    release perfect. So there are likely more commits later, but I\r
77    obviously don't want some git-describe version to end up in the final\r
78    tar file.\r
79 \r
80 2. I don't actually want to create a tag, (I *especially* don't want to\r
81    push it), until the release actually happens. That's the point of the\r
82    tag in my view, (to say "*this* is what I released"), so making the\r
83    tag early seems wrong, (and leaves the door open to make mistakes).\r
84 \r
85 Any suggestion for this part?\r
86 \r
87 > +include Makefile.version\r
88 > +\r
89 > +.PHONY: Makefile.version\r
90 > +Makefile.version:\r
91 > +     echo VERSION=3D$(if $(wildcard version),`cat version`,`git describe --d=\r
92 irty`) > $@\r
93 \r
94 Could that be simplified to just use $(shell) rather than a separate\r
95 file and an include?\r
96 \r
97 I suppose what we could do is to just have the creation of the version\r
98 file be part of the release process. That would be simple enough. Then\r
99 we could drop this rule:\r
100 \r
101 > +version:\r
102 > +     git describe > $@\r
103 \r
104 What do you think?\r
105 \r
106 =2DCarl\r
107 \r
108 --=-=-=\r
109 Content-Type: application/pgp-signature\r
110 \r
111 -----BEGIN PGP SIGNATURE-----\r
112 Version: GnuPG v1.4.10 (GNU/Linux)\r
113 \r
114 iD8DBQFLvQa56JDdNq8qSWgRAvdeAJ9LL2MhXC1yl6h2M3p9u9cOKxmG9wCfVdBy\r
115 Me31xsB+SIl96YMKaWDrfJI=\r
116 =nUAo\r
117 -----END PGP SIGNATURE-----\r
118 --=-=-=--\r