1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
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
|
