[Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

[Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

[Gavin Andresen]

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

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

[Luke-Jr]

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

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

[slush]

[-- 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 --]

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

[Luke-Jr]

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

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

[Pieter Wuille]

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

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

[Pieter Wuille]

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

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

[Gregory Maxwell]

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.

[Bitcoin-development] Fwd: IRC meeting agenda, 18:00 UTC Thursday

[Wladimir]

[-- 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 --]