Luke-Jr wrote: > I agree with Scott's assessment, although I would note that Debian *does* have > a suite that addresses the needs of Bitcoin: stable-updates. Mandatory > protocol rule changes would seem to fall within the "broken by the flow of > time" category. Thoughts?
I agree. Scott Howard wrote: > I think this is the way to go once bitcoin version "1.0" (or the > equivalent) is released. It requires users to enable the > stable-updates repository This is not necessary as the debian-installer already enables stable-updates by default. > we should block migration to testing until either upstream supports > stable releases or we have a volunteer that works closely enough with upstream > code (an upstream developer) that is will to backport security and network- > related fixes. Backporting is not necessary. The package can be version bumped for a security update, or version bumped in stable-updates for non-security changes. In the case of Bitcoin, mandatory network changes could arguably be considered "security updates" if they prevent the bitcoin server from working, because being unable to update the copy of the blockchain would open up additional attack vectors. tor has very similar restrictions (version <1.0, network protocol could change) and yet it is in both stable and testing. Testing already has other software (cgminger, bfgminer) that is reliant on the bitcoin protocol. Given all this, I do not think that the problems presented in this bug are a reason to hold up bitcoin from entering testing or, ultimately, stable. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
