MIME-Version: 1.0
In-Reply-To: <CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
From: Karl Johan Alm <karljohan-alm@garage.co.jp>
Date: Wed, 12 Jul 2017 10:22:59 +0900
Message-ID: <CALJw2w5uh8y1EMJdJVDhuFs3NG7LeM8T5HzfLHp8kXN15ryrXw@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap
Precedence: list

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.