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

[Wladimir <laanwj@gmail.com>]

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