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:date:message-id:subject:from:to:content-type;
        bh=ldwFpq18rAx4/rW9sfgCK0YrzSfRzMNCNPS0D5nbfAU=;
        b=I5w8i93UYOO+nLCPPMhRuS1TOInbH+iQHwYAeDGJ4zYOuoq51FLHJCnQKNF8BZz3c4
         OF8ZTUYuVaY+T3Sjf1725lVY2Y/XrzNyTYBatd23rhXRCY+vbnVgbEGQXgGXGCdbu9Tf
         Cmc2b8NNq1FDkQDnzsYjhBS0eosKLbRdWnG/9bLuD4VQA2qglrzuNJxH1/oFh1nF2GCE
         66J2xqUBbEykSFJgAUPxmlLx2zr6FdDEwFfS5Zzf0Xvlorddw4Duxw/Rjz9hQpGxdeNC
         PbZDOHi43JAQqTG5bNM5b+UIBeSWsJNdvQTcryNZSIBHyVyLGhkev/1yoBYtqsMJ3N7Z
         H57Q==
MIME-Version: 1.0
X-Received: by 10.28.3.133 with SMTP id 127mr91785040wmd.101.1451701808022;
 Fri, 01 Jan 2016 18:30:08 -0800 (PST)
Date: Fri, 1 Jan 2016 17:30:07 -0900
Message-ID: <CAC4O8c_p5bMB1cKzDEsQFSnbZvY3TgnczH94pO_qCoJmiv2iWQ@mail.gmail.com>
Subject: [geda-user] Merging stuff. How to make it happen
From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com, geda-developer AT Launchpad DOT net
Content-Type: multipart/alternative; boundary=001a11452782964eba052850aace
Reply-To: geda-user AT delorie DOT com

--001a11452782964eba052850aace
Content-Type: text/plain; charset=UTF-8

I want to merge the more trivial branches I've worked on now.

If there are more specific objections I'll fix or otherwise address them as
I have all the ones that have come up so far.

I stopped by the last sprint briefly and asked about this.  It sounds like
there's no definite policy for deciding when to merge things.  I therefore
propose that the following conditions should always be considered
sufficient for a merge into the main devel branch:

  * the person who wrote it says it's ready
  * at least one other person has looked at the patch
  * devel fixed or addressed any issues raised
  * it doesn't remove any functionality
  * it doesn't do anything known to be contentious

Whatever exact policy we use, it would be useful if we could get branches
merged faster than currently.  Developers tend to move from one initial
issue to closely related ones that they discover while working on the
first.  The changes involved frequently overlap, which makes maintaining
them as separate parallel branches hard.  So with slow merging you end up
with big branches.  Big branches are generally harder to manage, especially
when using the rebase approach.

Britton

--001a11452782964eba052850aace
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div style=3D"">I want to merge the more trivial branc=
hes I&#39;ve worked on now.</div><div style=3D""><br></div><div style=3D"">=
If there are more specific objections I&#39;ll fix or otherwise address the=
m as I have all the ones that have come up so far.</div><div style=3D""><br=
></div><div style=3D"">I stopped by the last sprint briefly and asked about=
 this.=C2=A0 It sounds like there&#39;s no definite policy for deciding whe=
n to merge things.=C2=A0 I therefore propose that the following conditions =
should always be considered sufficient for a merge into the main devel bran=
ch:</div><div style=3D""><br></div><div style=3D"">=C2=A0 * the person who =
wrote it says it&#39;s ready</div><div style=3D"">=C2=A0 * at least one oth=
er person has looked at the patch</div><div style=3D"">=C2=A0 * devel fixed=
 or addressed any issues raised</div><div style=3D"">=C2=A0 * it doesn&#39;=
t remove any functionality</div><div style=3D"">=C2=A0 * it doesn&#39;t do =
anything known to be contentious</div><div style=3D""><br></div><div style=
=3D"">Whatever exact policy we use, it would be useful if we could get bran=
ches merged faster than currently.=C2=A0 Developers tend to move from one i=
nitial issue to closely related ones that they discover while working on th=
e first.=C2=A0 The changes involved frequently overlap, which makes maintai=
ning them as separate parallel branches hard.=C2=A0 So with slow merging yo=
u end up with big branches.=C2=A0 Big branches are generally harder to mana=
ge, especially when using the rebase approach.=C2=A0</div><div style=3D""><=
br></div><div style=3D"">Britton</div></div>

--001a11452782964eba052850aace--