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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1SgPVY-0004nI-CC
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Jun 2012 00:07:52 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.46 as permitted sender)
client-ip=209.85.216.46; envelope-from=gmaxwell@gmail.com;
helo=mail-qa0-f46.google.com;
Received: from mail-qa0-f46.google.com ([209.85.216.46])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SgPVX-0004s9-P3
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Jun 2012 00:07:52 +0000
Received: by qadb17 with SMTP id b17so845225qad.12
for <bitcoin-development@lists.sourceforge.net>;
Sun, 17 Jun 2012 17:07:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.191.74 with SMTP id dl10mr24272698qab.65.1339978066288;
Sun, 17 Jun 2012 17:07:46 -0700 (PDT)
Received: by 10.229.144.205 with HTTP; Sun, 17 Jun 2012 17:07:45 -0700 (PDT)
In-Reply-To: <CAD2Ti28eC6A2+k8JfV3nXMLmye12K28rfCAorby87aXgV2ZGaQ@mail.gmail.com>
References: <CAD2Ti2_Z-mzHu_VG7fq+sgQj7CfdZ_nKoa7Q6nDObwBSL6yXgQ@mail.gmail.com>
<CAAS2fgQCc_-FgiXs0JABkAzZWNrbhhWYutvRgFLsnKYaEWDqwQ@mail.gmail.com>
<CAD2Ti29+=L+ss7fwivy+gfPFuE10sQdy68TGhL-30ngWKTLdQA@mail.gmail.com>
<CAAS2fgTHo0U+2U5vtbmTEiKB6rBHbfuRHsm-bcnRhSrs-2jZpw@mail.gmail.com>
<CAD2Ti28eC6A2+k8JfV3nXMLmye12K28rfCAorby87aXgV2ZGaQ@mail.gmail.com>
Date: Sun, 17 Jun 2012 20:07:45 -0400
Message-ID: <CAAS2fgQkiB1b1sepCcZ_Fw3P4Dd0DQVb=oEFJdjos6YqDAKdJg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: grarpamp <grarpamp@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(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
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SgPVX-0004s9-P3
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.6.x - detachdb in wrong place
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: Mon, 18 Jun 2012 00:07:52 -0000
On Sun, Jun 17, 2012 at 7:04 PM, grarpamp <grarpamp@gmail.com> wrote:
> Presumably the github/0.6.2 branch is safe for production?
0.6.2 is very widely used, more so than the other acceptably updated backpo=
rts.
> What degree of caution about wallet eating should be
> made for those using github/master?
I can't speak for anyone but myself:
I don't run master on wallets with large amounts of (non-testnet) coin
in them, except for a few times when I needed access to this feature
or that or just in a isolated capacity for testing. In any use with
real wallets I'd be sure to have good backups that never touched the
new code.
We have at various times had bugs in master that would corrupt wallets
(though IIRC not too severely) and have bugs that would burn coin both
in mining and in transactions (though again, I think not too
severely). My caution is not due to the risk being exceptionally
great but just because there is probably no remedy if things go wrong,
this caution is magnified by the fact that we don't currently have
enough testing activity on master.
Testnet exists so that people can test without fear of losing a lot of
funds and with the 0.7.0(git master) testnet reboot it should be more
usable than it has been. It would be very helpful if anyone offering
bitcoin services would setup parallel toy versions of your sites on
testnet=E2=80=94 it would bring more attention to your real services, it wo=
uld
give you an opportunity to get more testing done of your real
services, it would show some more commitment to software quality, and
it would let you take a more active role in advancing bitcoin
development by doing a little testing yourself that you couldn't do on
your production systems.
|
