[Bitcoin-development] 0.4.x stable branch

[Bitcoin-development] 0.4.x stable branch

[Luke-Jr]

Gavin, Jeff, et al:

A group of developers would be interested in maintaining 0.4 into the future 
as a stable branch (ie, bugfixes only). Would you be willing to plan on making 
the next mainline version after 0.4, being called 0.5, so we can release 
0.4.1, 0.4.2, etc? If we prepare the git repository + tags, would you guys be 
willing to make the actual release builds + source, and/or post such on the 
websites you administrate?

Luke and various others in #bitcoin-stable

Re: [Bitcoin-development] 0.4.x stable branch

[Gavin Andresen]

On Sun, Sep 18, 2011 at 7:30 PM, Luke-Jr <luke@dashjr.org> wrote:
> If we prepare the git repository + tags, would you guys be
> willing to make the actual release builds + source, and/or post such on the
> websites you administrate?
> Luke and various others in #bitcoin-stable

My initial reaction is no. Testing and bug-fixing is the bottleneck
for making core bitcoin better, and maintaining two release lines
won't make that better.

I also think that until we get to a "1.0" that we can all agree is
ready for everybody AND their grandma to use, using the word "stable"
would be dishonest.

Would we link to your binaries if you want to create 0.4.* releases,
build binaries, then QA test and release them?

I dunno-- what do other people think?

Eventually, when there are a bunch of bitcoin implementations to
choose from, I think bitcoin.org should look like bittorrent.org -- it
should become a forum for developers to exchange ideas about the
direction of bitcoin.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] 0.4.x stable branch

[Gregory Maxwell]

On Mon, Sep 19, 2011 at 8:49 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> My initial reaction is no. Testing and bug-fixing is the bottleneck
> for making core bitcoin better, and maintaining two release lines
> won't make that better.
>
> I also think that until we get to a "1.0" that we can all agree is
> ready for everybody AND their grandma to use, using the word "stable"
> would be dishonest.

I think the primary concern that they are attempting to address there
is providing a stable base bitcoind for miners, banks, and webservices
to apply their patches on top of.

Right now, if they want to keep up with development they are stuck
forward porting against often disruptive changes as just about
everyone running something of importance needs some patch or another
so you have people who are clearly in the know like Luke and tcatm
trailing development on some of their systems by many months.

This isn't healthy for the network.

I'm not convinced a bugfixes only branch will help much: Even bug fixes
will disrupt local fixes, and testing and supervising your upgrade usually
takes more effort than the forward porting.

I'd rather see more effort put into mainlining the changes people are
carrying sooner and restructuring code to better accommodate patches
which aren't suitable for mainline.  This will also encourage people
to make the fixes they're running publicly available, rather than
just keeping them private for competitive advantage.

Re: [Bitcoin-development] 0.4.x stable branch

[Amir Taaki]

>Eventually, when there are a bunch of bitcoin implementations to

>choose from, I think bitcoin.org should look like bittorrent.org -- it
>should become a forum for developers to exchange ideas about the
>direction of bitcoin.
>
>Gavin Andresen

Thanks for your support. This is a noble ideal and will ensure bitcoin's eventual success by serving as a neutral platform for discussions.

One step I've taken in this direction is to setup a process for proposing changes to the bitcoin protocol. See my other email to this list and this url:

  https://en.bitcoin.it/wiki/Bitcoin_Enhancement_Proposals

The first proposal BEP 0001 is copied from Python's PEP 0001 and is a good starting point. I've marked it as a draft since it's only a non-working proposal. After that with mutual consent and discussion, we can move it to active status and start to think about setting up an arbitration committee.

We should in general favour long discussion over voting. The Wikipedia model for resolving issues through hammering out details is superior to debian with a cycling board of voting members.

The bittorrent page looks like a good future ideal to model ourselves off of and the EP pages too:

  http://bittorrent.org/beps/bep_0000.html

BEP 0001 needs review and comments. As you can see, bittorrent did the exact same thing here (copying the PEP process) with success:

  http://bittorrent.org/beps/bep_0001.html

genjix / Amir Taaki

Re: [Bitcoin-development] 0.4.x stable branch

[Luke-Jr]

On Monday, September 19, 2011 8:49:08 AM Gavin Andresen wrote:
> On Sun, Sep 18, 2011 at 7:30 PM, Luke-Jr <luke@dashjr.org> wrote:
> > If we prepare the git repository + tags, would you guys be
> > willing to make the actual release builds + source, and/or post such on
> > the websites you administrate?
> > Luke and various others in #bitcoin-stable
> 
> My initial reaction is no. Testing and bug-fixing is the bottleneck
> for making core bitcoin better, and maintaining two release lines
> won't make that better.
> 
> I also think that until we get to a "1.0" that we can all agree is
> ready for everybody AND their grandma to use, using the word "stable"
> would be dishonest.

The problem with the current development model is that bugfixes are done 
alongside improvements, and code changes *always* have the potential to 
introduce new bugs, no matter how careful anyone is. So to stay on top of 
bugfixes right now implies risking new bugs being introduced. What good is 
getting one bug fixed, if it comes with 20 new yet-to-be-discovered bugs?

For example, 0.3.20.2 was the last version if bitcoind before people started 
experiencing random (albeit rare) deadlocks. However, there have been many 
bugfixes since then. Since there is no stable branch, someone who wishes to 
get those bugfixes is forced to either create their own stable branch from 
scratch, or risk getting all the new bugs introduced in the latest version 
(most of which are unknown at this time).

On the other hand, a stable 0.4.x branch can provide people with upgrades 
which they know make only the minimal changes required to fix bugs with a much 
smaller risk of new bugs being introduced (not only are there fewer changes, 
but bugfixes tend to also be less invasive changes). While there are arguably 
still various "must-have" features missing from 0.4, having a stable branch 
also allows people to maintain a stable+<feature I need> branch with greater 
ease too.

Re: [Bitcoin-development] 0.4.x stable branch

[Gregory Maxwell]

On Mon, Sep 19, 2011 at 11:00 AM, Luke-Jr <luke@dashjr.org> wrote:
> The problem with the current development model is that bugfixes are done
> alongside improvements, and code changes *always* have the potential to
> introduce new bugs, no matter how careful anyone is. So to stay on top of
> bugfixes right now implies risking new bugs being introduced. What good is
> getting one bug fixed, if it comes with 20 new yet-to-be-discovered bugs?

Bug fixes also introduce bugs. Considering the fairly small number of new
features added, I'd take a bet that most of the more recently introduced
bugs were the result of fixes not features.

Re: [Bitcoin-development] 0.4.x stable branch

[theymos]

On Monday, September 19, 2011 11:00 AM, "Luke-Jr" <luke@dashjr.org> wrote:
> The problem with the current development model is that bugfixes are
> done alongside improvements, and code changes *always* have the
> potential to introduce new bugs, no matter how careful anyone is. So
> to stay on top of bugfixes right now implies risking new bugs being
> introduced. What good is getting one bug fixed, if it comes with 20
> new yet-to-be-discovered bugs?

A stable version is a good idea. This is why I'm still using 0.3.19
(with some modifications): none of the bugfixes after this version help
me much, and I don't need any of the new features. I've also thought
about starting an unofficial stable version with my modifications to
0.3.19 and some backported bugfixes.

Re: [Bitcoin-development] 0.4.x stable branch

[Jeff Garzik]

This is the way it works for the kernel, the process on which I've
suggested we follow with bitcoin, to a small extent:

- Version X is released.  Linus now begins accepting pull requests
into torvalds/linux.git for X+1 ("merge window opens").  It is
strongly recommended that all pull requests have seen some exposure to
the public via "linux-next", which is a tree-of-trees generated from
pulling the trees of top developers.  linux-next is maintained by
another volunteer, Stephen Rothwell.

- After a week, Linus stops taking pull requests from subsystem
maintainers ("merge window closes").  At this point, a 2.5-month
stabilization and bug fix period begins.  No new features are merged
into torvalds/linux.git, and developers are expected to focus on bug
fixing.  Developers, of course, accept new features and changes into
their own trees and branches.  linux-next publishes these, while the
main torvalds/linux.git remains in bug fix mode.

- Three months after version X is released, version X+1 is released
from torvalds/linux.git top-of-tree, and the process begins anew.

- From time to time, _not_ every version, a Linux "enterprise"
distribution like Red Hat Enterprise Linux (plug plug) or Ubuntu LTS,
will maintain a kernel for a long time, for the benefit of their
customers who need stability over new feature.  Or, the community
simply decides that a kernel should be maintained for a longer period
of time.

In particular, Greg Kroah-Hartman (gregkh) maintains stable trees for
version X-1 and X-2, where he will accept fixes provided that the fix
(or a variant thereof) has been accepted in upstream.

In that case, an employee or volunteer maintains a stable branch of
the kernel.  They "backport" fixes from the main torvalds/linux.git
tree into their own gregkh/stable-2.6.36-linux.git tree.

Thus, we observe a few things that may be applied to bitcoin:

- decentralized operation, where stable branches and bitcoin-next are
not maintained by the core team
- the community decides which versions are important to maintain long term
- the core team may maintain a merge/stabilize/merge/stabilize
workflow, introducing new features without huge negative impact to
existing userbase

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

Re: [Bitcoin-development] 0.4.x stable branch

[Luke-Jr]

On Tuesday, September 20, 2011 3:10:16 PM Jeff Garzik wrote:
> Thus, we observe a few things that may be applied to bitcoin:

This is basically what the #bitcoin-stable team wants to do.

Re: [Bitcoin-development] 0.4.x stable branch

[Alex Waters]

I think what Jeff has said is ideal for a stable 1.0 or 1.1 release of
a kernal. I also think it's absolutely the direction we should be
heading in, but not this afternoon. The desire to keep a 0.4.x stable
branch is a symptom of a bigger QA problem, one that I am attempting
to address in general.

Gavin has reminded me to test, test, test. I implore anyone who clicks
the pull button to not only test their code, but write down how they
tested it. The issue tracker is somewhat out of control, and my
opinion is that a stable branch is not going to fix it.

This stage of development can be agitating, as you implement code in
the wild - it is outpaced or broken easily. The sooner we can get a
robust QA process to hammer out bugs, and process pulls - the closer
we are to a stable 1.0 release.

Please contact me if you would like to help contribute to the bug
hammering - I promise that we can find ways to make it
interesting/challenging. (working on a zapper too!)