From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R65i2-0002GU-Kq for bitcoin-development@lists.sourceforge.net; Tue, 20 Sep 2011 19:10:22 +0000 X-ACL-Warn: Received: from mail-gx0-f175.google.com ([209.85.161.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1R65i2-0001DR-0l for bitcoin-development@lists.sourceforge.net; Tue, 20 Sep 2011 19:10:22 +0000 Received: by gxk4 with SMTP id 4so773733gxk.34 for ; Tue, 20 Sep 2011 12:10:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.183.170 with SMTP id q30mr7481208yhm.42.1316545816500; Tue, 20 Sep 2011 12:10:16 -0700 (PDT) Received: by 10.236.25.3 with HTTP; Tue, 20 Sep 2011 12:10:16 -0700 (PDT) X-Originating-IP: [99.43.178.25] In-Reply-To: <201109181930.59565.luke@dashjr.org> References: <201109181930.59565.luke@dashjr.org> Date: Tue, 20 Sep 2011 15:10:16 -0400 Message-ID: From: Jeff Garzik To: Luke-Jr Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1R65i2-0001DR-0l Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] 0.4.x stable branch X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 19:10:22 -0000 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