1 Return-Path: <servilio@gmail.com>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id 2678E431FD0
\r
6 for <notmuch@notmuchmail.org>; Sat, 2 Jul 2011 08:59:07 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5
\r
12 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
\r
13 FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\r
14 Received: from olra.theworths.org ([127.0.0.1])
\r
15 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
16 with ESMTP id HDQxbtTlQ+Hh for <notmuch@notmuchmail.org>;
\r
17 Sat, 2 Jul 2011 08:59:05 -0700 (PDT)
\r
18 Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com
\r
19 [209.85.210.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
\r
20 (No client certificate requested)
\r
21 by olra.theworths.org (Postfix) with ESMTPS id B4280431FB6
\r
22 for <notmuch@notmuchmail.org>; Sat, 2 Jul 2011 08:59:05 -0700 (PDT)
\r
23 Received: by pzk6 with SMTP id 6so1913735pzk.26
\r
24 for <notmuch@notmuchmail.org>; Sat, 02 Jul 2011 08:59:04 -0700 (PDT)
\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
\r
26 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
\r
27 :cc:content-type:content-transfer-encoding;
\r
28 bh=CRingyQsCxb3mJeXkhKbWtmQ+OlLXDdF1aEf+IGqRps=;
\r
29 b=Y4zrZJfnQhYrkzrwoy1nUk5gqzPyA1kbknI8jGVOCAJ/eztz9qeeEO3+gV3a22ueBM
\r
30 13jQKM2+KKbRpgS3d+PsnG0BvfIE2RKK6g3I+AkiJaI7pPAiFxRQo5aqbcYGV76ZH7wc
\r
31 D+9TTDoRl4PLcsHtOJ7eHhDRQmRdMtaxrt744=
\r
33 Received: by 10.68.25.165 with SMTP id d5mr4899994pbg.32.1309622344750; Sat,
\r
34 02 Jul 2011 08:59:04 -0700 (PDT)
\r
35 Received: by 10.68.56.103 with HTTP; Sat, 2 Jul 2011 08:59:04 -0700 (PDT)
\r
36 In-Reply-To: <87tyb5mumf.fsf@zancas.localnet>
\r
37 References: <87y60hn0mg.fsf@zancas.localnet> <yun7h81brkn.fsf@aiko.keithp.com>
\r
38 <87tyb5mumf.fsf@zancas.localnet>
\r
39 Date: Sat, 2 Jul 2011 11:59:04 -0400
\r
41 <CAPFwwQhGy6a4Hes2-7r8B2J=eaE_+07p4FGoh5ds=Ws1_+5H5w@mail.gmail.com>
\r
42 Subject: Re: branchs and tags and merges oh my!
\r
43 From: servilio <servilio@gmail.com>
\r
44 To: David Bremner <david@tethera.net>
\r
45 Content-Type: text/plain; charset=UTF-8
\r
46 Content-Transfer-Encoding: quoted-printable
\r
47 Cc: notmuch@notmuchmail.org
\r
48 X-BeenThere: notmuch@notmuchmail.org
\r
49 X-Mailman-Version: 2.1.13
\r
51 List-Id: "Use and development of the notmuch mail system."
\r
52 <notmuch.notmuchmail.org>
\r
53 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
54 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
55 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
56 List-Post: <mailto:notmuch@notmuchmail.org>
\r
57 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
58 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
59 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
60 X-List-Received-Date: Sat, 02 Jul 2011 15:59:07 -0000
\r
62 On 1 July 2011 19:47, David Bremner <david@tethera.net> wrote:
\r
63 > On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard <keithp@keithp.com> wro=
\r
65 >> > 2) merge master onto the release branch
\r
67 >> This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging.
\r
69 > Can you elaborate? Naively it seems like one ends up with the same kind
\r
70 > of spur of history off of the 0.6 tag in both cases.
\r
72 > ----.--------------master
\r
74 > =C2=A0 =C2=A0 ---- 0.6 ---- bugfix
\r
79 > =C2=A0 =C2=A0 =C2=A0\ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
\r
80 > =C2=A0 =C2=A0 =C2=A0 ---- 0.6--------master
\r
81 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
\r
82 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0----- bugfix
\r
84 >> As an alternative, you probably should have simply put non-release
\r
85 >> patches on a separate 'feature branch' (probably residing in the feature
\r
86 >> author's repository) which would then be merged onto master post-0.6
\r
88 > Yes, that is certainly nice from a git history point of view. On the
\r
89 > other hand the point of separating the roles of feature merger from
\r
90 > release mechanic was to allow Carl more time to work on merging features
\r
91 > into master, and I'm not sure how turning master over to the release
\r
92 > manager helps that.
\r
94 What about having Carl do the merging of features into a develop
\r
95 branch[1], then the release manager prepares a release in a release
\r
96 branch, merging back and tagging into master when release is ready? A
\r
97 similar workflow could be followed for bugfix releases (branch to
\r
98 bugfix/release branch, prepare, merge back to master, tag).
\r
100 This workflow would keep a nice useful history while allowing even
\r
101 more independence between the feature merging and release process,
\r
106 [1] Or next, or whatever other name is better understood by the community.
\r