From: Jeff Garzik <jgarzik@exmulti•com>
To: Luke-Jr <luke@dashjr•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
Date: Wed, 10 Aug 2011 15:48:10 -0400 [thread overview]
Message-ID: <CA+8xBpdR6KsT6mWtHsrynKp0csQHHr+28DMunJjRhhBywv4GOQ@mail.gmail.com> (raw)
In-Reply-To: <201108101443.17015.luke@dashjr.org>
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
next prev parent reply other threads:[~2011-08-10 19:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-10 9:36 John Smith
2011-08-10 10:14 ` Matt Corallo
2011-08-10 10:26 ` John Smith
2011-08-10 10:43 ` Pieter Wuille
[not found] ` <CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>
2011-08-10 13:18 ` John Smith
2011-08-10 16:49 ` Gavin Andresen
2011-08-10 17:45 ` John Smith
2011-08-10 18:41 ` Gavin Andresen
2011-08-10 19:32 ` Andy Parkins
2011-08-10 19:57 ` Jeff Garzik
2011-08-10 21:13 ` Andy Parkins
2011-08-10 21:35 ` Jeff Garzik
2011-08-10 22:38 ` Andy Parkins
2011-08-11 3:20 ` Jeff Garzik
2011-08-11 5:47 ` Andy Parkins
2011-08-11 11:45 ` Joel Joonatan Kaartinen
2011-08-11 12:01 ` Christian Decker
2011-08-11 14:04 ` Andy Parkins
2011-08-11 12:11 ` Mike Hearn
2011-08-11 13:51 ` Andy Parkins
2011-08-11 12:19 ` John Smith
2011-08-11 13:08 ` Pieter Wuille
2011-08-10 18:43 ` Luke-Jr
2011-08-10 19:48 ` Jeff Garzik [this message]
2011-08-10 21:37 ` Jeff Garzik
2011-08-11 13:50 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+8xBpdR6KsT6mWtHsrynKp0csQHHr+28DMunJjRhhBywv4GOQ@mail.gmail.com \
--to=jgarzik@exmulti$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox