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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1SgT5h-0000e9-VG
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Jun 2012 03:57:25 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([173.242.112.54])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1SgT5h-00051V-62 for bitcoin-development@lists.sourceforge.net;
Mon, 18 Jun 2012 03:57:25 +0000
Received: from ishibashi.localnet (unknown [97.96.85.141])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id AFB7C560556;
Mon, 18 Jun 2012 03:57:19 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Mon, 18 Jun 2012 03:57:11 +0000
User-Agent: KMail/1.13.7 (Linux/3.4.0-gentoo-nestfix; KDE/4.8.1; x86_64; ; )
References: <CAD2Ti2_Z-mzHu_VG7fq+sgQj7CfdZ_nKoa7Q6nDObwBSL6yXgQ@mail.gmail.com>
<201206180002.43785.luke@dashjr.org>
<CAD2Ti28q2_c=AgUjapQQvLLoMcT4ay50q_PuYbwA3820747t1A@mail.gmail.com>
In-Reply-To: <CAD2Ti28q2_c=AgUjapQQvLLoMcT4ay50q_PuYbwA3820747t1A@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201206180357.13430.luke@dashjr.org>
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SgT5h-00051V-62
Subject: Re: [Bitcoin-development] 0.6.x - detachdb in wrong place
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: Mon, 18 Jun 2012 03:57:26 -0000
On Monday, June 18, 2012 3:27:52 AM grarpamp wrote:
> So I get that github/master is the obvious top of things.
> But in looking at where the tags are between repositories,
> it's still not clear to me what the workflow is.
Workflow is all new development takes place in master during release windows.
Eventually, those windows close and master is cleaned up and bugfix'd for the
next 0.x release. Occasionally, when 0.N.0 has some problem before the next
release window opens, Gavin will use it to roll a 0.N.1 (and recently even a
0.N.2 and 0.N.2.2). Once the release window for the next 0.N version opens,
I import the (last bugfix-only commit after the final 0.N.M release made in
master) into the stable repository as the 0.N.x branch, and begin applying
backports. When there's significant backports, I'll tag another 0.N.M from the
branch and possibly release Windows binaries. Usually this happens around the
same time as master becomes the next 0.N.0 release.
> Example...
>
> There are these release tarballs on sourceforge, which all have
> tags in github, yet no tags in gitorious. There are no 'x' branches
> on github, yet there is one release applicable branch on gitorious.
>
> I guess I'd expect to see, that if as hinted by Luke that gitorious
> has the stable trees, that there would be release tags there, laid
> down at some comfy point in time on the 'x' stable branches there.
> (The stable branches inheriting new code from master). But there
> are no such tags.
I guess I've been neglecting to update the stable repo with releases tagged in
master. It should be fixed now.
Luke
|
