diff options
| author | Jeff Garzik <jgarzik@exmulti.com> | 2011-08-10 15:48:10 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2011-08-10 19:48:20 +0000 |
| commit | 6ea4d5caf661eb4cc1d0caadc65702bcdde0cc60 (patch) | |
| tree | 5b648cadd2c14855a892c4cdf1f51276afab9bdb | |
| parent | 367b4a99086fe77ff3da1e8c4bde116028579cbb (diff) | |
| download | pi-bitcoindev-6ea4d5caf661eb4cc1d0caadc65702bcdde0cc60.tar.gz pi-bitcoindev-6ea4d5caf661eb4cc1d0caadc65702bcdde0cc60.zip | |
Re: [Bitcoin-development] Change to multiple executables?
| -rw-r--r-- | ba/3ba71fba07daffa4ba7537d8bcac1e6867eef9 | 119 |
1 files changed, 119 insertions, 0 deletions
diff --git a/ba/3ba71fba07daffa4ba7537d8bcac1e6867eef9 b/ba/3ba71fba07daffa4ba7537d8bcac1e6867eef9 new file mode 100644 index 000000000..7e0f741ce --- /dev/null +++ b/ba/3ba71fba07daffa4ba7537d8bcac1e6867eef9 @@ -0,0 +1,119 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <jgarzik@exmulti.com>) id 1QrElI-00068R-Fr + for bitcoin-development@lists.sourceforge.net; + Wed, 10 Aug 2011 19:48:20 +0000 +X-ACL-Warn: +Received: from mail-iy0-f171.google.com ([209.85.210.171]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1QrElD-0006j4-ML + for bitcoin-development@lists.sourceforge.net; + Wed, 10 Aug 2011 19:48:20 +0000 +Received: by iyf13 with SMTP id 13so1916076iyf.30 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 10 Aug 2011 12:48:10 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.42.150.69 with SMTP id z5mr3082572icv.67.1313005690129; Wed, + 10 Aug 2011 12:48:10 -0700 (PDT) +Received: by 10.42.226.4 with HTTP; Wed, 10 Aug 2011 12:48:10 -0700 (PDT) +X-Originating-IP: [99.173.148.118] +In-Reply-To: <201108101443.17015.luke@dashjr.org> +References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com> + <CABsx9T0Yvssr04AeT3B8+Gj43hV=P0Uw6M0f+NBNygnAyruQ4A@mail.gmail.com> + <CAJNQ0stfYFN2YCGq-be5D-XW+81ZkVVM_jHHonSy2OHsNyN1Cw@mail.gmail.com> + <201108101443.17015.luke@dashjr.org> +Date: Wed, 10 Aug 2011 15:48:10 -0400 +Message-ID: <CA+8xBpdR6KsT6mWtHsrynKp0csQHHr+28DMunJjRhhBywv4GOQ@mail.gmail.com> +From: Jeff Garzik <jgarzik@exmulti.com> +To: Luke-Jr <luke@dashjr.org> +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: 1QrElD-0006j4-ML +Cc: bitcoin-development@lists.sourceforge.net +Subject: Re: [Bitcoin-development] Change to multiple executables? +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 10 Aug 2011 19:48:20 -0000 + +On Wed, Aug 10, 2011 at 2:43 PM, Luke-Jr <luke@dashjr.org> wrote: +> On Wednesday, August 10, 2011 1:45:42 PM John Smith wrote: +>> 0.3.x -> small, compatible changes, bugfixes, like now +>> 0.4.x -> trunk, more impactful changes, refactorings, eventual major +>> release +> +> It seems there's room for some kind of "experimental" branch as well, +> including features that might not make it into any stable release (due to lack +> of use/interest or whatever). + +In kernel land there exists "linux-next" Stephen Rothwell maintains a +tree that is linux -tip, plus a list of trees & branches to pull from +various individual developers. For example, linux-next pulls my SATA +tree from libata-dev.git branch NEXT. + +Each developer is expected to publish changes they feel are ready for +upstream. Developers are expected to "play nicely" and coordinate +amongst themselves when two trees include conflicting changes. +Trivial merge conflicts are handled by Stephen Rothwell, who does +merging, build testing and such of the final set-of-N-trees result. +More difficult merge conflicts are coordinated by the developers +themselves, who work together to create a temporary "merge tree" that +is then pulled by the linux-next maintainer. + +linux-next is the always moving, regenerated daily target where +developers stage [in their opinion] upstream-ready changes. + +Thus Linus's linux.git development process really looks like the +following, when linux-next is included in the picture: + +1. Version X-1 is released, on day 0. +2. Merge window for version X opens, on day 0. +3. Linus pulls all changes that have seen testing in linux-next, over +the -rc window (step #6, below) +4. Merge window closes, on day 7. +5. Version X-rc1 is released, on day 7. +6. Only bug fixes are accepted now (hopefully seen at least 24 hours +of testing in linux-next, unless urgency demands otherwise). All new +development is done in developer trees and branches, and is +automatically published nightly in linux-next. +7. Version X is released, on day 90. + +Thus "upstream" stays almost constantly stable, except for the short +1-week merge window period, and linux-next comprises the rolling +"development version" where new changes are staged. + +Note the subtle but important distinction between this and maintaining +a strict 'bugfix' and 'development' branch system like John Smith +described. The underlying linux-next dependent trees may be rebased +at any time, and so linux-next is constantly regenerated, rather than +being a cumulative history of choatic development. Major changes can +and will be staged, de-staged, and re-staged during development, and +maintaining a strict "official development branch" methodology is less +flexible. + +Here is an example linux-next report. Stephen sends one, daily, with +each linux-next tree generated: +http://marc.info/?l=linux-next&m=131295044704945&w=2 + +As it applies to bitcoin, this "bitcoin-next" approach may simply be +layered on top of the current methodology. All it requires is a +volunteer who maintains this tree-of-trees, and wha-la: bitcoin has a +development branch. + +-- +Jeff Garzik +exMULTI, Inc. +jgarzik@exmulti.com + + |