summaryrefslogtreecommitdiff
path: root/d1/6af032a342f955c8af0e994369a1e4bcab1e7a
blob: d38dc5b1caffa00bc875e3c776639153fd47e165 (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gmaxwell@gmail.com>) id 1V1pc3-0000Zf-T0
	for bitcoin-development@lists.sourceforge.net;
	Wed, 24 Jul 2013 03:19:39 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.173 as permitted sender)
	client-ip=209.85.217.173; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f173.google.com; 
Received: from mail-lb0-f173.google.com ([209.85.217.173])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1V1pc2-00012K-3Z
	for bitcoin-development@lists.sourceforge.net;
	Wed, 24 Jul 2013 03:19:39 +0000
Received: by mail-lb0-f173.google.com with SMTP id v1so79573lbd.32
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 23 Jul 2013 20:19:31 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.27.169 with SMTP id u9mr15607308lag.8.1374635971397;
	Tue, 23 Jul 2013 20:19:31 -0700 (PDT)
Received: by 10.112.160.104 with HTTP; Tue, 23 Jul 2013 20:19:31 -0700 (PDT)
In-Reply-To: <20130724023526.GD1009@zooko.com>
References: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
	<smumwpcg8sw.fsf@linuxpal.mit.edu>
	<CAAS2fgTxU4fb6n+fHPomOVDkEY+uoepd7QTPMxbxALYm2Sf3kg@mail.gmail.com>
	<20130724023526.GD1009@zooko.com>
Date: Tue, 23 Jul 2013 20:19:31 -0700
Message-ID: <CAAS2fgQJ6B5q4xmB-UfC=jeiYDkqxK71oTvtp7MqHXRn43duTQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: zooko <zooko@zooko.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
	(gmaxwell[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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: 1V1pc2-00012K-3Z
Cc: 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 03:19:40 -0000

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-han=
ded --
> telling someone else how to do their job -- and they might not notice the
> 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 that =
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.