1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1V1uQq-0003eM-8V
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Jul 2013 08:28:24 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.45 as permitted sender)
client-ip=209.85.219.45; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f45.google.com;
Received: from mail-oa0-f45.google.com ([209.85.219.45])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V1uQn-0006vP-Se
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Jul 2013 08:28:23 +0000
Received: by mail-oa0-f45.google.com with SMTP id j1so265408oag.4
for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Jul 2013 01:28:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.71.38 with SMTP id r6mr28807750obu.64.1374654496470;
Wed, 24 Jul 2013 01:28:16 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.23.36 with HTTP; Wed, 24 Jul 2013 01:28:16 -0700 (PDT)
In-Reply-To: <CAAS2fgQJ6B5q4xmB-UfC=jeiYDkqxK71oTvtp7MqHXRn43duTQ@mail.gmail.com>
References: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
<smumwpcg8sw.fsf@linuxpal.mit.edu>
<CAAS2fgTxU4fb6n+fHPomOVDkEY+uoepd7QTPMxbxALYm2Sf3kg@mail.gmail.com>
<20130724023526.GD1009@zooko.com>
<CAAS2fgQJ6B5q4xmB-UfC=jeiYDkqxK71oTvtp7MqHXRn43duTQ@mail.gmail.com>
Date: Wed, 24 Jul 2013 10:28:16 +0200
X-Google-Sender-Auth: lKXL2uUDApbD4uQ626IxjsP-v1Q
Message-ID: <CANEZrP00vN0TFsxnpSO3RoC_aiAbGS9LG9KXM1+KqWRv8YsJXg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8fb1f56cf37d2004e23db0fc
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1V1uQn-0006vP-Se
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Greg Troxel <gdt@work.lexort.com>
Subject: Re: [Bitcoin-development] Linux packaging letter
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 08:28:24 -0000
--e89a8fb1f56cf37d2004e23db0fc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Yeah, if anyone wants to make the letter more digestable please do propose
an alternative, although by this point it's probably not worth it as people
have already signed.
FWIW, Gregory is right that my original draft was much more brusque. The
pain in the packaging relationship travels both ways. I have in the past
wasted a lot of time due to bogus packaging applied by non-expert packagers
that broke things. In fact the project I was a part of adopted a policy of
automatically closing bug reports from people who were using distributor
packages (any distro) because the quality was so inconsistent and so many
subtle bugs were introduced.
If packagers hear upstreams cry about packaging a lot, I think you should
keep an open mind that some of them probably know what they're talking
about. We really shouldn't have to beg and cajole here. Saying "we have our
reasons and we want you to stop" should be enough.
On Wed, Jul 24, 2013 at 5:19 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote=
:
> On Tue, Jul 23, 2013 at 7:35 PM, zooko <zooko@zooko.com> wrote:
> > I think some
> > package maintainers might perceive this version of the letter as
> high-handed --
> > telling someone else how to do their job -- and they might not notice t=
he
> > actual facts included in the letter explaining why Bitcoin really *is*
> > different than a lot of software.
>
> Bummer, because this was a explicit consideration while writing it and
> a concern several people had with the initial draft Mike did.
>
> We're very much aware that upstreams frequently cry (wolf) at the
> mutilation of their unique and precious snowflake.
>
> The intention was that second paragraph acknowledging the many good
> motivations for the existing norms and the third paragraph talking
> about consensus systems would address these concerns=E2=80=94 showing tha=
t we
> aren't totally clueless, and pointing out that we have an actually
> unusual situation. In intermediate drafts they were longer and more
> elaborate, but we were struggling against length and trying to avoid
> delving into a highly technical discussion which would lose anyone who
> wasn't already very interested.
>
> We also compromised on an initial approach of "please don't package
> this at all" to "please understand first", in part at the protest of
> our gentoo package (which also bundles leveldb but hard locks it to an
> exact version in the package system with exact build flags, which is a
> sophisticated compromise which might not generalize to other
> distributors) maintainer (uh, Luke-Jr, not exactly the most
> representative sample).
>
> As a first step it's at least important to know that there is a
> concern here shared by a bunch of people. Helping talk people through
> understanding it is part of the job here. I certainly didn't expect
> the discussion to stop with the letter but getting it out there is a
> way to start the discussion and make it more likely that we have it
> again with the next packager who comes around.
>
> I guess the first priority though is avoiding gratuitously offending
> people. Can anyone point out any specific tweaks that would reduce
> initial bristling?
>
> On Tue, Jul 23, 2013 at 6:45 PM, Douglas Huff <dhuff@jrbobdobbs.org>
> wrote:
> > Honestly, until I read the quoted part of your response,
>
> Oh be nice. If any of this were easy it would all be _done_ already. :)
>
> There is naturally some tension when people with different priorities
> and backgrounds interact, ... I've seen a lot of upstreams run into
> disagreements with packagers the result is usually better for
> everyone.
>
>
> -------------------------------------------------------------------------=
-----
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=3D48808831&iu=3D/4140/ostg.=
clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--e89a8fb1f56cf37d2004e23db0fc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yeah, if anyone wants to make the letter more digestable p=
lease do propose an alternative, although by this point it's probably n=
ot worth it as people have already signed.<div><br></div><div>FWIW, Gregory=
is right that my original draft was much more brusque. The pain in the pac=
kaging relationship travels both ways. I have in the past wasted a lot of t=
ime due to bogus packaging applied by non-expert packagers that broke thing=
s. In fact the project I was a part of adopted a policy of automatically cl=
osing bug reports from people who were using distributor packages (any dist=
ro) because the quality was so inconsistent and so many subtle bugs were in=
troduced.=C2=A0</div>
<div><br></div><div>If packagers hear upstreams cry about packaging a lot, =
I think you should keep an open mind that some of them probably know what t=
hey're talking about. We really shouldn't have to beg and cajole he=
re. Saying "we have our reasons and we want you to stop" should b=
e enough.</div>
<div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div=
class=3D"gmail_quote">On Wed, Jul 24, 2013 at 5:19 AM, Gregory Maxwell <sp=
an dir=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">=
gmaxwell@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Jul 23, 2013 at 7:=
35 PM, zooko <<a href=3D"mailto:zooko@zooko.com">zooko@zooko.com</a>>=
wrote:<br>
> I think some<br>
> package maintainers might perceive this version of the letter as high-=
handed --<br>
> telling someone else how to do their job -- and they might not notice =
the<br>
> actual facts included in the letter explaining why Bitcoin really *is*=
<br>
> different than a lot of software.<br>
<br>
</div>Bummer, because this was a explicit consideration while writing it an=
d<br>
a concern several people had with the initial draft Mike did.<br>
<br>
We're very much aware that upstreams frequently cry (wolf) at the<br>
mutilation of their unique and precious snowflake.<br>
<br>
The intention was that second paragraph acknowledging the many good<br>
motivations for the existing norms and the third paragraph talking<br>
about consensus systems would address these concerns=E2=80=94 showing that =
we<br>
aren't totally clueless, and pointing out that we have an actually<br>
unusual situation. In intermediate drafts they were longer and more<br>
elaborate, but we were struggling against length and trying to avoid<br>
delving into a highly technical discussion which would lose anyone who<br>
wasn't already very interested.<br>
<br>
We also compromised on an initial approach of "please don't packag=
e<br>
this at all" to "please understand first", in part at the pr=
otest of<br>
our gentoo package (which also bundles leveldb but hard locks it to an<br>
exact version in the package system with exact build flags, which is a<br>
sophisticated compromise which might not generalize to other<br>
distributors) maintainer (uh, Luke-Jr, not exactly the most<br>
representative sample).<br>
<br>
As a first step it's at least important to know that there is a<br>
concern here shared by a bunch of people. Helping talk people through<br>
understanding it is part of the job here. =C2=A0I certainly didn't expe=
ct<br>
the discussion to stop with the letter but getting it out there is a<br>
way to start the discussion and make it more likely that we have it<br>
again with the next packager who comes around.<br>
<br>
I guess the first priority though is avoiding gratuitously offending<br>
people. =C2=A0Can anyone point out any specific tweaks that would reduce<br=
>
initial bristling?<br>
<div class=3D"im"><br>
On Tue, Jul 23, 2013 at 6:45 PM, Douglas Huff <<a href=3D"mailto:dhuff@j=
rbobdobbs.org">dhuff@jrbobdobbs.org</a>> wrote:<br>
> Honestly, until I read the quoted part of your response,<br>
<br>
</div>Oh be nice. If any of this were easy it would all be _done_ already. =
:)<br>
<br>
There is naturally some tension when people with different priorities<br>
and backgrounds interact, ... I've seen a lot of upstreams run into<br>
disagreements with packagers the result is usually better for<br>
everyone.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
See everything from the browser to the database with AppDynamics<br>
Get end-to-end visibility with application monitoring from AppDynamics<br>
Isolate bottlenecks and diagnose root cause in seconds.<br>
Start your free trial of AppDynamics Pro today!<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48808831&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48808831&iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--e89a8fb1f56cf37d2004e23db0fc--
|
