From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VYBuG-0006Ko-Se for bitcoin-development@lists.sourceforge.net; Mon, 21 Oct 2013 09:36:12 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.49 as permitted sender) client-ip=209.85.215.49; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f49.google.com; Received: from mail-la0-f49.google.com ([209.85.215.49]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VYBuF-0000K7-Iv for bitcoin-development@lists.sourceforge.net; Mon, 21 Oct 2013 09:36:12 +0000 Received: by mail-la0-f49.google.com with SMTP id eh20so294739lab.8 for ; Mon, 21 Oct 2013 02:36:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.57.49 with SMTP id f17mr12085815lbq.26.1382348164829; Mon, 21 Oct 2013 02:36:04 -0700 (PDT) Received: by 10.112.159.233 with HTTP; Mon, 21 Oct 2013 02:36:04 -0700 (PDT) In-Reply-To: <5264D1DB.5060107@250bpm.com> References: <38895569-E6E1-4576-9E36-B00B53F9D3CC@me.com> <201310192229.19932.luke@dashjr.org> <19909B49-0895-4130-99FB-9A116140CFE9@me.com> <20131019235746.GA29032@savin> <9EF588BB-14B5-495A-8253-82574DCB1A8A@me.com> <20131020224316.GA25280@savin> <20131021062555.GA10784@savin> <80401395-792A-4637-A75C-1D499C547F98@me.com> <20131021064320.GA17190@savin> <5264D1DB.5060107@250bpm.com> Date: Mon, 21 Oct 2013 11:36:04 +0200 Message-ID: From: Melvin Carvalho To: Martin Sustrik Content-Type: multipart/alternative; boundary=001a1133eaca5217fe04e93d03bf X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: doubleclick.net] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VYBuF-0000K7-Iv Cc: Bitcoin Development Subject: Re: [Bitcoin-development] A critique of bitcoin open source community X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 09:36:13 -0000 --001a1133eaca5217fe04e93d03bf Content-Type: text/plain; charset=ISO-8859-1 On 21 October 2013 09:03, Martin Sustrik wrote: > On 21/10/13 08:52, Jean-Paul Kogelman wrote: > > How about putting them into sub directories that map onto the status of > the BIP? > > > > Reading BIP 1, that would make: > > > > Accepted > > Active > > Draft > > Deferred > > Final > > Rejected > > Replaced > > Withdrawn > > Have it been considered to do this via IETF? The process there is > hardened by 40 years of experience and 7000+ RFCs. Probably better than > anything you can devise yourself. > IETF is great for some things. I think the bitcoin URI scheme is being registered with them. However the process can take many years to get to an RFC, for something relatively simple, not to mention there can be costs too Given that crypto currencies are a relatively new field, I am unsure the IETF has a wealth of expertise in this area, compared with the core devs Maybe IETF is better to standardize some of the communications or serialization components, but not so much the BIPs. Or perhaps some of the BIPs can be written up as "Informational" rather than "Proposed Standard" in the RFC format, and reviewed I've followed quite a few FLOSS projects over the years. Overall, I've been amazingly impressed with the BIP process (dont forget it's used in other systems too -- python?). It seems an agile process, that strikes an great balance between needed features, and documentation. I think that's exactly what will continue bitcoin's momentum in the short to medium term. > > Martin > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a1133eaca5217fe04e93d03bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 21 October 2013 09:03, Martin Sustrik <sustrik@250bpm.com&= gt; wrote:
On 21/10/13 08:52, Jean-Pa= ul Kogelman wrote:
> How about putting them into sub directories that map onto the status o= f the BIP?
>
> Reading BIP 1, that would make:
>
> Accepted
> Active
> Draft
> Deferred
> Final
> Rejected
> Replaced
> Withdrawn

Have it been considered to do this via IETF? The process there is
hardened by 40 years of experience and 7000+ RFCs. Probably better than
anything you can devise yourself.

IETF = is great for some things.=A0 I think the bitcoin URI scheme is being regist= ered with them.

However the process can take many years to get to an= RFC, for something relatively simple, not to mention there can be costs to= o

Given that crypto currencies are a relatively new field, I a= m unsure the IETF has a wealth of expertise in this area, compared with the= core devs

Maybe IETF is better to standardize some of th= e communications or serialization components, but not so much the BIPs.=A0 = Or perhaps some of the BIPs can be written up as "Informational" = rather than "Proposed Standard" in the RFC format, and reviewed
I've followed quite a few FLOSS projects over the years.= =A0 Overall, I've been amazingly impressed with the BIP process (dont f= orget it's used in other systems too -- python?).=A0 It seems an agile = process, that strikes an great balance between needed features, and documen= tation.=A0 I think that's exactly what will continue bitcoin's mome= ntum in the short to medium term.
=A0

Martin

---------------------------------------------------------------------------= ---
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most fr= om
the latest Intel processors and coprocessors. See abstracts and register &g= t;
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D60135031&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a1133eaca5217fe04e93d03bf--