Re: [Bitcoin-development] BIP process

2014-10-19 Thread xor
On Wednesday, October 15, 2014 10:29:43 AM Wladimir wrote: B) I also think it makes sense to move the BIP discussion (both about the BIP process and individual BIPs) to a separate mailing list. bitcoin-development currently has a dual function: discussion of Bitcoin Core implementation

Re: [Bitcoin-development] BIP process

2014-10-19 Thread Btc Drak
On Sun, Oct 19, 2014 at 8:17 AM, xor x...@freenetproject.org wrote: I joined the list when Bitcoin was already in the 10-billions of market capitalization, and it actually really surprised me how low the traffic is here given the importance of Bitcoin. So as a random stranger to the

Re: [Bitcoin-development] BIP process

2014-10-19 Thread Wladimir
On Sun, Oct 19, 2014 at 9:17 AM, xor x...@freenetproject.org wrote: So as a random stranger to the project, I would vote against that if I was allowed to. There really should be *more* discussion here, and splitting the list up won't help with that. The problem is not one of traffic, but of

Re: [Bitcoin-development] BIP process

2014-10-19 Thread Thomas Zander
On Sunday 19. October 2014 09.17.51 xor wrote: I joined the list when Bitcoin was already in the 10-billions of market capitalization, and it actually really surprised me how low the traffic is here given the importance of Bitcoin. I gather that actual code changes to bitcoin-core and

Re: [Bitcoin-development] BIP process

2014-10-19 Thread odinn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Earlier in the discussion I suggested Discourse so that the BIP page would be able to look smoother and draw more input. Unsystem forum is run on Discourse and has twitter, github, and e-mail integration. For those who haven't explored it, here is

Re: [Bitcoin-development] BIP process

2014-10-16 Thread Thomas Zander
On Wednesday 15. October 2014 11.36.58 Wladimir wrote: We're also having problems with people failing to comment on things, not even I looked at this and have no opinion, which is really obstructing things. Well - the only way to avoid that is to set a reasonable deadline, after which

Re: [Bitcoin-development] BIP process

2014-10-16 Thread Thomas Zander
On Wednesday 15. October 2014 20.13.11 Mike Hearn wrote: Plus its moderation features suck, its mail archiving features suck, etc. It essentially has no redeeming features at all. Other than it being open source, an open platform with no lock-in 'features' and it works with everyone that uses

Re: [Bitcoin-development] BIP process

2014-10-16 Thread Oliver Egginger
15.10.2014 at 20:13 Mike Hearn wrote: For a project that is based on digital signatures, it's really bad that the mailing list is incompatible with Yahoo's mail signatures must be valid policy. # Mailman: Do not break existing DKIM signatures DEFAULT_SUBJECT_PREFIX = DEFAULT_MSG_HEADER =

[Bitcoin-development] BIP process

2014-10-15 Thread Wladimir
Hello, I'm trying to create a bit of process around the https://github.com/bitcoin/bips repository. A) Currently a lot of pulls are open for various BIPs and it is not clear who should comment on them, or who decides on changes to be merged. Currently all BIP changes have to go through the

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Gregory Maxwell
On Wed, Oct 15, 2014 at 8:29 AM, Wladimir laa...@gmail.com wrote: Hello, I'm trying to create a bit of process around the https://github.com/bitcoin/bips repository. A) Currently a lot of pulls are open for various BIPs and it is not clear who should comment on them, or who decides on

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Wladimir
This all makes a lot of sense to me, and would help a lot with the workflow. Unfortunately github pulls and issues really have nothing to faciltate a multistage workflow... e.g. where something can go through several steps. Indeed, pull requests don't have a status. It would be possible to

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Gavin Andresen
RE: process: I like author == primary control, and an assume they will do the right thing, revert if they don't RE: separate mailing list for BIP discussion: Great idea. Jeff Garzik was looking for a better mailing list solution than SourceForge, but assuming there isn't a clearly better

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Mike Hearn
Great idea. Jeff Garzik was looking for a better mailing list solution than SourceForge, but assuming there isn't a clearly better solution I think we should create a strictly moderated bitcoin-bips@lists.sourceforge list. Let's stay away from SF.net or any mailman-controlled lists if at

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Adam Back
please not google groups *, I'd vote for sourceforge or other simple open list software over google groups. Adam * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that your address

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Peter Todd
On Wed, Oct 15, 2014 at 04:54:57PM +0100, Adam Back wrote: please not google groups *, I'd vote for sourceforge or other simple open list software over google groups. Adam * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Mike Hearn
I don't care much what exact list software/service is used, but lists.sf.net hasn't changed in years and is basically dying. Trashing all @yahoo accounts because ancient mailman does a MITM attack on people's email is no good, it's not any better than a web proxy that breaks every SSL connection.

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Btc Drak
On Wed, Oct 15, 2014 at 4:54 PM, Adam Back a...@cypherspace.org wrote: please not google groups *, I'd vote for sourceforge or other simple open list software over google groups. Please not sourceforge. * Google lists are somehow a little proprietary or gmail lockin focused eg it makes

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Cory Fields
Sounds like this is what you're after, it's a fairly new feature: https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments I've been meaning to use it in a PR to try it out. Cory On Wed, Oct 15, 2014 at 5:36 AM, Wladimir laa...@gmail.com wrote: This all makes a lot of sense to

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Peter Todd
On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote: * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that your address is associated with a gmail account. Quite

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Luke Dashjr
On Wednesday, October 15, 2014 7:40:04 PM Peter Todd wrote: On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote: * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that

Re: [Bitcoin-development] BIP process

2011-10-20 Thread Christian Decker
On Thu, Oct 20, 2011 at 7:02 AM, Alex Waters ampe...@gmail.com wrote: • I propose that BIPs be wiki pages, with a social convention that the Author gets final word if any editing wars break out. ACK Does it have to be wiki pages if we're going through an editorial process anyway, and there

Re: [Bitcoin-development] BIP process

2011-10-19 Thread Alex Waters
• I propose that BIPs be wiki pages, with a social convention that the Author gets final word if any editing wars break out. ACK • If he's willing, I propose that Amir take the role of BIP editor. ACK • I think bitcoin is still too small to have a specialized bitcoin-ideas mailing

[Bitcoin-development] BIP process

2011-10-18 Thread Gavin Andresen
Amir started the get more formal about changes to bitcoin ball rolling by creating BIP 0001, starting from the Python PEP / BitTorrent BEP processes: https://en.bitcoin.it/w/index.php?title=BIP_0001 The idea is to use BIPs for changes that may or will affect every bitcoin implementation (not to