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
|
Return-Path: <marcopon@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 742BDE8D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 16:43:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com
[209.85.215.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C576B169
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 16:43:08 +0000 (UTC)
Received: by mail-lf0-f51.google.com with SMTP id y184so228635410lfc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 08:43:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=vAMrikVXpjHLtLDjqai7T0wNiTcfEmeoSxkwxD25j4I=;
b=0y1yILGNsdHtY5N5c8FKJDG+PgyPuny7EvNZnBDsaFAgH5Jk3wkdO/MWZ0Fzvd7FIk
O6Nv4nNDpmoRHEhXjppfNeuYjQEuKmA2Kd597X3P7rMRfb5P+QSINg3veFjo6s7To9GB
LeFc6g6Y9TJ599mI5N0oigjAQWDOZHJCIKuTH9Hv7GW4khmvCa9PJwudnnjZc7fiHpVc
iEUWbkAcs8G5rNzucxyqLWy18V7apDdpuTha/EIAIrMYLMcH4cTT/xbTzTlByy9rH/gx
eBP5SVD0mCquNYLWpPIMSiKkxm24miT+vOakTrvLUxkfwYXkuPZCa/8EjsF4qxbWG6aT
lbhg==
X-Received: by 10.25.83.193 with SMTP id h184mr3408991lfb.6.1451493786758;
Wed, 30 Dec 2015 08:43:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.186.228 with HTTP; Wed, 30 Dec 2015 08:42:47 -0800 (PST)
From: Marco Pontello <marcopon@gmail.com>
Date: Wed, 30 Dec 2015 17:42:47 +0100
Message-ID: <CAE0pACJf=aQFFTwRyWn+8SxS2P-v5FmG77kbC35rq_0p42CDEw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1142507e8db1da0528203bac
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 31 Dec 2015 23:05:34 +0000
Subject: [bitcoin-dev] BIP numbers
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Dec 2015 16:43:09 -0000
--001a1142507e8db1da0528203bac
Content-Type: text/plain; charset=UTF-8
Sorry to ask again but... what's up with the BIP number assignments?
I thought that it was just more or less a formality, to avoid conflicts and
BIP spamming. And that would be perfectly fine.
But since I see that it's a process that can take months (just looking at
the PR request list), it seems that something different is going on. Maybe
it's considered something that give an aura of officiality of sorts? But
that would make little sense, since that should come eventually with
subsequents steps (like adding a BIP to the main repo, and eventual
approvation).
Having # 333 assigned to a BIP, should just mean that's easy to refer to a
particular BIP.
That seems something that could be done quick and easily.
What I'm missing? Probably some historic context?
Thanks!
--001a1142507e8db1da0528203bac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Sorry to ask again but... what's up with the BIP =
number assignments?</div><div>I thought that it was just more or less a for=
mality, to avoid conflicts and BIP spamming. And that would be perfectly fi=
ne.</div><div>But since I see that it's a process that can take months =
(just looking at the PR request list), it seems that something different is=
going on. Maybe it's considered something that give an aura of officia=
lity of sorts? But that would make little sense, since that should come eve=
ntually with subsequents steps (like adding a BIP to the main repo, and eve=
ntual approvation).</div><div><br></div><div>Having # 333 assigned to a BIP=
, should just mean that's easy to refer to a particular BIP.</div><div>=
That seems something that could be done quick and easily.=C2=A0</div><div><=
br></div><div>What I'm missing? Probably some historic context?=C2=A0</=
div><div>Thanks!<br></div>
</div>
--001a1142507e8db1da0528203bac--
|
