* [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday @ 2012-11-06 18:47 Gavin Andresen 2012-11-06 19:13 ` Luke-Jr 2012-11-07 19:37 ` Pieter Wuille 0 siblings, 2 replies; 9+ messages in thread From: Gavin Andresen @ 2012-11-06 18:47 UTC (permalink / raw) To: Bitcoin Dev Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to be a good time for the core dev team to meet on the #bitcoin-dev freenode IRC channel to chat. I'd like to talk about: o Can we put together a TODO list to get to a 0.8 release candidate ? o Is it time to feature-freeze 0.8 and work on just testing the new features and fixing existing bugs (the issues list keeps getting longer and longer ... )? o BIP process: are we happy with how it is working? What can we do to improve it? What else should we talk about? -- -- Gavin Andresen ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday 2012-11-06 18:47 [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday Gavin Andresen @ 2012-11-06 19:13 ` Luke-Jr 2012-11-06 19:56 ` slush 2012-11-07 19:37 ` Pieter Wuille 1 sibling, 1 reply; 9+ messages in thread From: Luke-Jr @ 2012-11-06 19:13 UTC (permalink / raw) To: bitcoin-development On Tuesday, November 06, 2012 6:47:34 PM Gavin Andresen wrote: > Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to > be a good time for the core dev team to meet on the #bitcoin-dev > freenode IRC channel to chat. > > I'd like to talk about: > > o Can we put together a TODO list to get to a 0.8 release candidate ? > > o Is it time to feature-freeze 0.8 and work on just testing the new > features and fixing existing bugs (the issues list keeps getting > longer and longer ... )? Not much has changed besides internal workings, right? Though perhaps that's still significant enough for 0.8. > o BIP process: are we happy with how it is working? What can we do to > improve it? Amir seems to be more and more absent these days, so it might be nice to setup a successor failsafe in the event that he cannot be reached. It would be a shame for the BIP process to fall apart merely because we can't get numbers assigned. But more important to the success of BIP today, I think, is encouraging wider community participation. The stratum mining mess seems to be a direct result of lack of participation in the GBT BIP process (resulting in it not being as ideal as some pools desire) and lack of any peer review/contribution toward the stratum protocol. What can we do to increase awareness of BIP and encourage more collaboration? Luke ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday 2012-11-06 19:13 ` Luke-Jr @ 2012-11-06 19:56 ` slush 2012-11-06 22:12 ` Luke-Jr 0 siblings, 1 reply; 9+ messages in thread From: slush @ 2012-11-06 19:56 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1217 bytes --] On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr <luke@dashjr•org> wrote: > But more important to the success of BIP today, I think, is encouraging > wider > community participation. It's not about BIP process, it's possibly about content of particular proposals. > The stratum mining mess seems to be a direct result There's no mess with stratum mining, except in your head. There's no requirement to have BIP for everything what people do. Stratum is NOT related to bitcoin protocol or bitcoin implementation, it is just custom, pooled-mining extension and bitcoin network doesn't need to know about Stratum existence at all. > and lack of any peer review/contribution toward the stratum protocol. There have been peer review of the protocol. You wanted to say "I was not invited to do peer review", right? Please don't start it AGAIN and stop bashing Stratum in your posts, at least in bitcoin-dev mailing list. I promised to write BIP draft for Stratum, I proposed and implemented get_transactions method to allow Stratum jobs inspection. What more do you want, seriously? I'm soo tired by you, Luke. slush P.S. I'm sorry that other developers had to read such posts. I'll try to sit on my hands next time. [-- Attachment #2: Type: text/html, Size: 1940 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday 2012-11-06 19:56 ` slush @ 2012-11-06 22:12 ` Luke-Jr 0 siblings, 0 replies; 9+ messages in thread From: Luke-Jr @ 2012-11-06 22:12 UTC (permalink / raw) To: slush; +Cc: bitcoin-development On Tuesday, November 06, 2012 7:56:23 PM slush wrote: > On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr <luke@dashjr•org> wrote: > > But more important to the success of BIP today, I think, is encouraging > > wider community participation. > > It's not about BIP process, it's possibly about content of particular > proposals. > ... > I promised to write BIP draft for Stratum, I proposed and implemented > get_transactions method to allow Stratum jobs inspection. What more do you > want, seriously? I'm soo tired by you, Luke. Perhaps the problem lies in misunderstanding of the BIP process, then, rather than awareness of it. BIP isn't just "write a document"; that's just the first step. The main thing is that it gets peer review, changed to meet the community's needs, and when done should result in a common standard suitable to the needs of the whole community. Whatever the reason, there was a failure of key members of the community to participate in the GBT BIP process and ensure it addressed their needs/wants; identifying and addressing that is something that would improve the BIP process. get_transactions is a step in the right direction, and I don't think anyone expects Stratum to reach the same level as GBT overnight considering it took months for GBT (though I have no doubt now that the GBT discussions have taken place, that some dedicated individual could probably combine the two if they dedicated a few days to it). My comments, however, were not intended to bash stratum or mere complain about the past (it can't be changed), but an attempt to learn from the past and figure out how we can improve things the next time around. Luke ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday 2012-11-06 18:47 [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday Gavin Andresen 2012-11-06 19:13 ` Luke-Jr @ 2012-11-07 19:37 ` Pieter Wuille 2012-11-08 9:19 ` Mike Hearn 1 sibling, 1 reply; 9+ messages in thread From: Pieter Wuille @ 2012-11-07 19:37 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev On Tue, Nov 6, 2012 at 7:47 PM, Gavin Andresen <gavinandresen@gmail•com> wrote: > Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to > be a good time for the core dev team to meet on the #bitcoin-dev > freenode IRC channel to chat. Ok, good. -- Pieter ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday 2012-11-07 19:37 ` Pieter Wuille @ 2012-11-08 9:19 ` Mike Hearn 2012-11-08 12:56 ` Pieter Wuille ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Mike Hearn @ 2012-11-08 9:19 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1133 bytes --] I won't be able to make it this time. My feeling is IRC is a good place to bounce ideas around when time and people happen to be available, but having meetings there will inevitably lead to decision making that's better done in a slower manner via email. Comments: BIP process: are we happy with how it is working? What can we do to improve it? Needing some kind of process to allocate a number is over the top. I skipped this for the bloom filtering BIP. We should take off the part of the {{BIP}} template that says "don't just pick a number and add a bip" - that's exactly what people should do. I'm not sure there's any need for an editing role either. Is it time to feature-freeze 0.8 I'd like more time to get the bloom filtering work in. It'll be easier to promote the 0.8 release if we can sell it as "important scalability/performance improvement for the network, upgrade to help Bitcoin keep growing", as whilst there's no real auto update or organized people who religiously update promotion is very important. I think ultraprune + bloom filtering is the two major scalability improvements we have right now. [-- Attachment #2: Type: text/html, Size: 2031 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday 2012-11-08 9:19 ` Mike Hearn @ 2012-11-08 12:56 ` Pieter Wuille 2012-11-08 13:07 ` Gregory Maxwell [not found] ` <CA+s+GJDVLLv8troMfeyWoOwM3EH4GHYtd=bzUgmg_ZegVT6kXw@mail.gmail.com> 2 siblings, 0 replies; 9+ messages in thread From: Pieter Wuille @ 2012-11-08 12:56 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev On Thu, Nov 08, 2012 at 10:19:05AM +0100, Mike Hearn wrote: > Comments: > > BIP process: are we happy with how it is working? What can we do to improve > it? > > Needing some kind of process to allocate a number is over the top. I > skipped this for the bloom filtering BIP. We should take off the part of > the {{BIP}} template that says "don't just pick a number and add a bip" - > that's exactly what people should do. I'm not sure there's any need for an > editing role either. Right now, there seem to be little problems with allocation and viability of proposed BIPs, with hardly any reviewing/formal allocation being done in practice. In the past there have been collisions though, and there also have been nonsensical proposals. I'm in favor of some moderate form of process, but if the process becomes a burden more than a help, there is clearly a problem. It seems there is also little attractiveness to writing BIPs. If many proposals do not result in useful discussion, there is little incentive to write one except for those proposals that absolutely need to (p2p protocol, block validity rules, ...). That's a pity in my opinion - I'd like to see non-core proposals related to Bitcoin being discussed more often as well. > > Is it time to feature-freeze 0.8 > > I'd like more time to get the bloom filtering work in. It'll be easier to > promote the 0.8 release if we can sell it as "important > scalability/performance improvement for the network, upgrade to help > Bitcoin keep growing", as whilst there's no real auto update or organized > people who religiously update promotion is very important. I think > ultraprune + bloom filtering is the two major scalability improvements we > have right now. Agree, I think Bloom filtering should make it into 0.8 - it's a critical step to make SPV clients more useful for end users. Regarding ultraprune, there are a few TODOs left: * Auto-migrate old data (depends on -reindex, for which there is a pullreq) * UTXO set consistency checks at startup (-checklevel) -- Pieter ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday 2012-11-08 9:19 ` Mike Hearn 2012-11-08 12:56 ` Pieter Wuille @ 2012-11-08 13:07 ` Gregory Maxwell [not found] ` <CA+s+GJDVLLv8troMfeyWoOwM3EH4GHYtd=bzUgmg_ZegVT6kXw@mail.gmail.com> 2 siblings, 0 replies; 9+ messages in thread From: Gregory Maxwell @ 2012-11-08 13:07 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev On Thu, Nov 8, 2012 at 4:19 AM, Mike Hearn <mike@plan99•net> wrote: > Is it time to feature-freeze 0.8 > > I'd like more time to get the bloom filtering work in. It'll be easier to > promote the 0.8 release if we can sell it as "important > scalability/performance improvement for the network, upgrade to help Bitcoin I agree on getting the bloom filtering stuff in for 0.8, though I don't think it'll need any marketing at all— ultraprune speaks for itself. :P I'm also concerned about overselling it for miners and merchants when the ultraprune stuff is such a major change. Since the current changes will just need a lot of testing and soaking time which is pretty much independent of RPC and GUI changes it might be unfortunate to feature freeze those things and then have a long delay just on QA for the other stuff. I do think we need to talk about what we think we need to o to get what we have now ready for release. ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <CA+s+GJDVLLv8troMfeyWoOwM3EH4GHYtd=bzUgmg_ZegVT6kXw@mail.gmail.com>]
* [Bitcoin-development] Fwd: IRC meeting agenda, 18:00 UTC Thursday [not found] ` <CA+s+GJDVLLv8troMfeyWoOwM3EH4GHYtd=bzUgmg_ZegVT6kXw@mail.gmail.com> @ 2012-11-08 13:10 ` Wladimir 0 siblings, 0 replies; 9+ messages in thread From: Wladimir @ 2012-11-08 13:10 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1952 bytes --] On Thu, Nov 8, 2012 at 10:19 AM, Mike Hearn <mike@plan99•net> wrote: > I won't be able to make it this time. My feeling is IRC is a good place > to bounce ideas around when time and people happen to be available, but > having meetings there will inevitably lead to decision making that's better > done in a slower manner via email. Well I think regularly scheduled IRC meetings are a good idea, as for some smaller decisions quick brainstorming tends to work better than long e-mail threads. But indeed big and important decisions should be posted on the mailing list too. > Comments: > > BIP process: are we happy with how it is working? What can we do to improve > it? > > Needing some kind of process to allocate a number is over the top. I > skipped this for the bloom filtering BIP. We should take off the part of > the {{BIP}} template that says "don't just pick a number and add a bip" - > that's exactly what people should do. I'm not sure there's any need for an > editing role either. > Agreed in that we don't need a "number allocation king". But some rules for the numbering can be good to keep sanity. What about very simply "everyone that wants to create a BIP picks the next available number and reserves that page on the Wiki?". > > Is it time to feature-freeze 0.8 > > I'd like more time to get the bloom filtering work in. It'll be easier to > promote the 0.8 release if we can sell it as "important > scalability/performance improvement for the network, upgrade to help > Bitcoin keep growing", as whilst there's no real auto update or organized > people who religiously update promotion is very important. I think > ultraprune + bloom filtering is the two major scalability improvements we > have right now. > I'm not sure about a full feature freeze. I agree it could be wise not do any more changes of the scale of ultraprune before 0.9, to give some stability to fix the kinks in the current version. Wladimir [-- Attachment #2: Type: text/html, Size: 3693 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-11-08 13:10 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-06 18:47 [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday Gavin Andresen
2012-11-06 19:13 ` Luke-Jr
2012-11-06 19:56 ` slush
2012-11-06 22:12 ` Luke-Jr
2012-11-07 19:37 ` Pieter Wuille
2012-11-08 9:19 ` Mike Hearn
2012-11-08 12:56 ` Pieter Wuille
2012-11-08 13:07 ` Gregory Maxwell
[not found] ` <CA+s+GJDVLLv8troMfeyWoOwM3EH4GHYtd=bzUgmg_ZegVT6kXw@mail.gmail.com>
2012-11-08 13:10 ` [Bitcoin-development] Fwd: " Wladimir
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox