* [Bitcoin-development] 0.4.x stable branch @ 2011-09-18 23:30 Luke-Jr 2011-09-19 12:49 ` Gavin Andresen 2011-09-20 19:10 ` Jeff Garzik 0 siblings, 2 replies; 10+ messages in thread From: Luke-Jr @ 2011-09-18 23:30 UTC (permalink / raw) To: Gavin Andresen, Jeff Garzik; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] 0.4.x stable branch 2011-09-18 23:30 [Bitcoin-development] 0.4.x stable branch Luke-Jr @ 2011-09-19 12:49 ` Gavin Andresen 2011-09-19 13:03 ` Gregory Maxwell ` (2 more replies) 2011-09-20 19:10 ` Jeff Garzik 1 sibling, 3 replies; 10+ messages in thread From: Gavin Andresen @ 2011-09-19 12:49 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] 0.4.x stable branch 2011-09-19 12:49 ` Gavin Andresen @ 2011-09-19 13:03 ` Gregory Maxwell 2011-09-19 13:48 ` Amir Taaki 2011-09-19 15:00 ` Luke-Jr 2 siblings, 0 replies; 10+ messages in thread From: Gregory Maxwell @ 2011-09-19 13:03 UTC (permalink / raw) To: Gavin Andresen; +Cc: bitcoin-development 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] 0.4.x stable branch 2011-09-19 12:49 ` Gavin Andresen 2011-09-19 13:03 ` Gregory Maxwell @ 2011-09-19 13:48 ` Amir Taaki 2011-09-19 15:00 ` Luke-Jr 2 siblings, 0 replies; 10+ messages in thread From: Amir Taaki @ 2011-09-19 13:48 UTC (permalink / raw) To: bitcoin-development >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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] 0.4.x stable branch 2011-09-19 12:49 ` Gavin Andresen 2011-09-19 13:03 ` Gregory Maxwell 2011-09-19 13:48 ` Amir Taaki @ 2011-09-19 15:00 ` Luke-Jr 2011-09-19 15:06 ` Gregory Maxwell 2011-09-20 4:41 ` theymos 2 siblings, 2 replies; 10+ messages in thread From: Luke-Jr @ 2011-09-19 15:00 UTC (permalink / raw) To: Gavin Andresen; +Cc: bitcoin-development 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] 0.4.x stable branch 2011-09-19 15:00 ` Luke-Jr @ 2011-09-19 15:06 ` Gregory Maxwell 2011-09-20 4:41 ` theymos 1 sibling, 0 replies; 10+ messages in thread From: Gregory Maxwell @ 2011-09-19 15:06 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] 0.4.x stable branch 2011-09-19 15:00 ` Luke-Jr 2011-09-19 15:06 ` Gregory Maxwell @ 2011-09-20 4:41 ` theymos 1 sibling, 0 replies; 10+ messages in thread From: theymos @ 2011-09-20 4:41 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] 0.4.x stable branch 2011-09-18 23:30 [Bitcoin-development] 0.4.x stable branch Luke-Jr 2011-09-19 12:49 ` Gavin Andresen @ 2011-09-20 19:10 ` Jeff Garzik 2011-09-20 20:37 ` Luke-Jr 1 sibling, 1 reply; 10+ messages in thread From: Jeff Garzik @ 2011-09-20 19:10 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] 0.4.x stable branch 2011-09-20 19:10 ` Jeff Garzik @ 2011-09-20 20:37 ` Luke-Jr 2011-09-21 14:24 ` Alex Waters 0 siblings, 1 reply; 10+ messages in thread From: Luke-Jr @ 2011-09-20 20:37 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-development 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] 0.4.x stable branch 2011-09-20 20:37 ` Luke-Jr @ 2011-09-21 14:24 ` Alex Waters 0 siblings, 0 replies; 10+ messages in thread From: Alex Waters @ 2011-09-21 14:24 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development 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!) ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-09-21 14:24 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-18 23:30 [Bitcoin-development] 0.4.x stable branch Luke-Jr 2011-09-19 12:49 ` Gavin Andresen 2011-09-19 13:03 ` Gregory Maxwell 2011-09-19 13:48 ` Amir Taaki 2011-09-19 15:00 ` Luke-Jr 2011-09-19 15:06 ` Gregory Maxwell 2011-09-20 4:41 ` theymos 2011-09-20 19:10 ` Jeff Garzik 2011-09-20 20:37 ` Luke-Jr 2011-09-21 14:24 ` Alex Waters
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox