From: Karl Johan Alm <karljohan-alm@garage•co.jp>
To: Gregory Maxwell <greg@xiph•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap
Date: Wed, 12 Jul 2017 10:22:59 +0900 [thread overview]
Message-ID: <CALJw2w5uh8y1EMJdJVDhuFs3NG7LeM8T5HzfLHp8kXN15ryrXw@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
On Wed, Jul 12, 2017 at 6:11 AM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
> and release process once the basic technology is done; because it's
> only past that point that guarantees can really start being made.
Bitcoin development differs from Linux kernel development in a number
of obvious ways, such as the fact Bitcoin is being "patched in
flight". The current political situation over Bitcoin development is
also quite different, with scalability being a major concern for a lot
of users, and conflicting views leading to risky technical gambles.
Having *something* like a roadmap that gives the average user some
insights into what exactly is being planned for Bitcoin is very
desirable, arguably even necessary, in particular for the scaling
solutions. Putting deadlines and dates in would of course be highly
irresponsible, as no one can predict how much of their free time
volunteer developers will put into the project in advance (or whether
they will stick around for the next X months or stop being
contributors).
I think there is necessity for a document that describes the project
intentions for scaling solutions, but I don't think adding dates and
deadlines is appropriate. That may or may not be a roadmap. I imagine
such a document would be updated regularly as appropriate, which means
it may be less of a roadmap than the traditional kind.
next prev parent reply other threads:[~2017-07-12 1:23 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 16:50 Paul Sztorc
2017-07-11 16:03 ` Chris Stewart
2017-07-11 16:49 ` Adam Back
2017-07-11 20:01 ` Pieter Wuille
2017-07-11 20:36 ` Paul Sztorc
2017-07-11 21:40 ` Pieter Wuille
2017-07-11 22:49 ` Paul Sztorc
2017-07-11 21:16 ` CryptAxe
2017-07-11 20:18 ` Paul Sztorc
2017-07-11 21:31 ` Gregory Maxwell
2017-07-11 22:27 ` Paul Sztorc
2017-07-11 21:11 ` Gregory Maxwell
2017-07-11 21:40 ` Gregory Maxwell
2017-07-11 22:17 ` Paul Sztorc
2017-07-11 22:41 ` Tao Effect
2017-07-11 22:57 ` Paul Sztorc
2017-07-11 23:12 ` Tao Effect
2017-07-12 0:21 ` Paul Sztorc
2017-07-12 7:27 ` Jacob Eliosoff
2017-07-12 19:19 ` Chris Stewart
2017-07-12 19:24 ` Tao Effect
2017-07-12 19:34 ` Chris Stewart
2017-07-12 19:42 ` Tao Effect
2017-07-12 19:54 ` CryptAxe
2017-07-12 21:55 ` Tao Effect
2017-07-12 22:07 ` CryptAxe
2017-07-11 23:36 ` Bryan Bishop
2017-07-12 0:07 ` Gregory Maxwell
2017-07-12 1:40 ` Paul Sztorc
2017-07-12 2:48 ` Bryan Bishop
2017-07-12 3:33 ` Gregory Maxwell
2017-07-12 6:17 ` [bitcoin-dev] how to disable segwit in my build? Dan Libby
2017-07-13 1:04 ` Gregory Maxwell
2017-07-13 13:11 ` Federico Tenga
2017-07-13 13:39 ` Hampus Sjöberg
2017-07-13 16:19 ` Dan Libby
2017-07-13 16:35 ` Jameson Lopp
2017-07-13 21:58 ` Dan Libby
2017-07-13 22:50 ` Hampus Sjöberg
2017-07-13 23:20 ` Dan Libby
2017-07-14 8:52 ` Hampus Sjöberg
2017-07-14 9:03 ` Tier Nolan
2017-07-13 23:19 ` Lucas Clemente Vella
2017-07-13 16:05 ` Dan Libby
2017-07-14 21:11 ` Troy Benjegerdes
2017-07-13 1:48 ` Anthony Towns
2017-07-13 16:13 ` Dan Libby
2017-07-12 1:22 ` Karl Johan Alm [this message]
2017-07-12 9:37 ` [bitcoin-dev] Updating the Scaling Roadmap Tom Zander
2017-07-12 9:02 ` Tom Zander
2017-07-11 23:28 ` Anthony Towns
2017-07-17 17:13 ` [bitcoin-dev] Updating the Scaling Roadmap [Update] Paul Sztorc
2017-07-17 18:49 ` Alex Morcos
2017-07-17 20:13 ` Paul Sztorc
2017-07-17 21:50 ` Peter Todd
[not found] ` <20170717214704.ksegcrdqf3zeslah@fedora-23-dvm>
2017-07-17 22:04 ` Paul Sztorc
2017-07-11 22:26 [bitcoin-dev] Updating the Scaling Roadmap Steve Davis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALJw2w5uh8y1EMJdJVDhuFs3NG7LeM8T5HzfLHp8kXN15ryrXw@mail.gmail.com \
--to=karljohan-alm@garage$(echo .)co.jp \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox