There seemed to be some agreement on IRC - after a bit of haranguing by
myself :) -- that large refactors should (a) occur over a small window of
time and (b) have a written plan beforehand.
On Tue, Sep 22, 2015 at 7:49 PM, Dave Scotese
wrote:
> If I'm reading this situation correctly, Jeff is
On Wed, Sep 23, 2015 at 1:49 AM, Dave Scotese wrote:
> If I'm reading this situation correctly, Jeff is basically pointing out that
> developers need more links (hooks, rungs, handholds, data points, whatever
> you want to call them) so that they can see all the things his email
> insinuated are m
On Tue, Sep 22, 2015 at 8:27 PM, Gavin Andresen wrote:
> You need to write a high-level overview document, explaining things like:
>
> + Who should use libconsensus
Separating the consensus code is extremely important for less risky
and wider contributions regardless of what is exposed.
But once
If I'm reading this situation correctly, Jeff is basically pointing out
that developers need more links (hooks, rungs, handholds, data points,
whatever you want to call them) so that they can see all the things his
email insinuated are missing (a plan, order, sense, etc.). He didn't say
these thin
On Tue, Sep 15, 2015 at 6:10 AM, Jeff Garzik via bitcoin-dev
wrote:
> [collating a private mail and a github issue comment, moving it to a
> better forum]
>
> On libconsensus
> ---
> In general there exists the reasonable goal to move consensus state
> and code to a specific, separate
>
> What one needs for that, I think, is a library that communicate with the
> node, and which offers functionality abstractly be similar to 'git pull':
> give me the tree path from my current known tip to the best tip, and supply
> the block hashes (and block data) along the way.
>
This is exactl
You're aware that my entire stack was built around this model and I've even
built a fully fledged desktop GUI, multisig account manager, and servers
supporting pull and event subscription atop it, right?
On September 17, 2015 5:07:20 PM PDT, "Wladimir J. van der Laan via
bitcoin-dev" wrote:
>O
On Wed, Sep 16, 2015 at 06:29:28PM -0400, Peter Todd via bitcoin-dev wrote:
> I've run into a number of cases where companies were maintaining forks
> of Bitcoin Core unnecessarily, where a different, loosely coupled,
> architecture could do what they needed to do without including the new
> logic
On Tue, Sep 15, 2015 at 12:10:37AM -0400, Jeff Garzik via bitcoin-dev wrote:
> Refactors however have a very real negative impact.
> bitcoin/bitcoin.git is not only the source tree in the universe.
> Software engineers at home, at startups, and at major companies are
> maintaining branches of their
On Tue, Sep 15, 2015 at 4:26 PM, Jeff Garzik wrote:
> The problem comes with the impact of an unfocused stream of refactors to
> key code.
>
> For example, there is much less long term developer impact if refactoring
> were _accelerated_, scheduled to be performed in a one-week sprint. There
> i
I basically agree with what has been said here.
Refactoring efforts should be well-coordinated. Their short-term impact can be
quite disruptive, although if done correctly, longer-term they make it even
easier for downstream developers to add and merge changes.
By scheduling move-only changes,
Drak,
I would say that the refactoring does actually fulfill some conditions you
mention:
- move-only is almost always clearly separated out
- the refactoring is not controversial _in minimis_ - meaning, the
individual pull request is not controversial.
The problem comes with the impact of an unf
I also share a lot of Jeff's concerns about refactoring and have voiced
them several times on IRC and in private to Jorge, Wladamir and Greg. I
meant to do a write up but never got around to it. Jeff has quite
eloquently stated the various problems. I would like to share my thoughts
on the matter b
[collating a private mail and a github issue comment, moving it to a
better forum]
On libconsensus
---
In general there exists the reasonable goal to move consensus state
and code to a specific, separate lib.
To someone not closely reviewing the seemingly endless stream of
libconsensu
14 matches
Mail list logo
