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: References: Date: Thu, 4 Feb 2016 08:28:42 +0100 Message-ID: Subject: Re: [geda-user] unstable_master branch From: "Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" To: gEDA User Mailing List 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] 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