X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=59hUph8ikvMmg2ZXLgQFyYgJYdXAwIM3bO4o6k1ftho=;
        b=zdMuPzKtIeRckTgyRySYtciV5zCLawu21VSFDUary7poNd5/2A8icoWdWV+3DW7k48
         ToANOwC3kbhX5+Zd7dSxLjK7PIyoWvFoyKsCXBRFFr7eZ+QLmxQN6wFHxW3JlboY5gmZ
         NHFo8LWuuAujsGpr7EqZxNUKvuqqghwArbN+wl+t3knTl9TObiRLiFmQGQi3TTCn67ZN
         iQ/ZfyCTHa8ExOE3YQKsLUnl3N598eAuDuAYxpQ/s/CoXKOhSZFWamM7xi1It2LVkPcd
         szCE5T8ApOXNvX26zr4bu+AQYuSgAPFpW2z8ATidTbWZI6PRlsq4yN66sSMbV3IeRDwk
         KNDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:content-type;
        bh=59hUph8ikvMmg2ZXLgQFyYgJYdXAwIM3bO4o6k1ftho=;
        b=Z9viAutky5tEtFiKgyT6L/QgRCXXRAjL16FbqZr3ddNMKdrdIJ7EnKd48pDAgKXJPn
         VKQ8RH+Tb0C7AzU0a/6jP0WBS1CaTyeCzLzNJ2mb6IwqCLGY8TFb1XQwe9hoz6w+uP5k
         9vm8SY5VV865htk8PQyJUo0YVDsZsI+HTDBYe2y9RRZrY48+/EUT6LTBp9Uy7WIhjr2g
         voB7RskyEvhBq9iwU6T5fApmgdluSKkL0kN2zkbGPGLgwD0ebHQLEwv3JD2ZKVgkBnGd
         h5/e5Fi7WBb60bNwD1tdIl8PWRFBNDlroeuZZtJy8YN/VwJs4uU5Rx2a3OpWNz7yq5yg
         0x4w==
X-Gm-Message-State: AG10YOQ8Jaao+xh/x4SqGtN4RiR77Z4ql+OptooQnpTzSs6CY9ny+ELqt594IpXnAwflmNoBuRwYYhilLObnpA==
MIME-Version: 1.0
X-Received: by 10.107.130.20 with SMTP id e20mr8729126iod.77.1454570922518;
 Wed, 03 Feb 2016 23:28:42 -0800 (PST)
In-Reply-To: <CAC4O8c_fPco1L6LJ0wWuh6yvWM4+XM8RdWqyO4bkmAD-Oe5Lqg@mail.gmail.com>
References: <CAC4O8c_fPco1L6LJ0wWuh6yvWM4+XM8RdWqyO4bkmAD-Oe5Lqg AT mail DOT gmail DOT com>
Date: Thu, 4 Feb 2016 08:28:42 +0100
Message-ID: <CACwWb3AJs7CX7VYhr+S1Wm-jp0Tt=Y64Gbb=GzgGiZiNCo0xWQ@mail.gmail.com>
Subject: Re: [geda-user] unstable_master branch
From: "Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA User Mailing List <geda-user AT delorie DOT com>
Content-Type: text/plain; charset=UTF-8
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

This kind of branching strategy is always leads to this question. I'm
more supporting this route:

1. You define your goal accurately
2. You create your feature branch
3. You do the development on your feature branch.
3a. You may create experimental branches from your feature branch, and
merge it back to the feature branch.
4. Do some tests (smoke tests, or whatever) (I don't know if we have one)
5. Merge back to master.


I don't think you can live without rebasing. If someone in the
meantime merges something into the master, you shall rebase your
feature branch if you want those lines of code.

Lev

On Wed, Feb 3, 2016 at 10:16 PM, Britton Kerin
(britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]
<geda-user AT delorie DOT com> wrote:
> This got discussed previously and there didn't seem to be any major
> opposition, so I'd like to elevate it to formal proposal.
>
> The idea is to have a branch where we merge new work, allowing devs to
> test each others branches more easily and automatically and work off
> their own branches without having to juggle things between branches,
> while still maintaining master in a release-ready state.
>
> How it should work (IMO):
>
> 1.  same people in charge of merging into it.  They have a long
> history of project stewardship and this isn't intended as an end-run
> around their authority
>
> 2.  about the same criteria for merge as now, maybe only a little bit
> more aggressive and trusting of individual devs.  devs should
> understand that a merge into unstable_master isn't a free pass into
> master: in fact if it causes trouble in unstable_master the odds of
> getting into master go down, not up.
>
> 3.  Working things are eventually merged into master in the same order
> they were applied to unstable_master.
>
> 4.  always merge, never rebase.  This makes 3 much easier and
> preserves an accurate history.  In the past there's been an
> inclination to rebase, but it's not really needed for a project of pcb
> size.  Peter Clifton indicated that after consultation with another
> long-standing dev who favored merge, he would support merging
> everything, even trivial branches.
>
> Britton