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=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VXHpNQATYKX2iVaOmGmqMwqLG0NQJ/3VmzK6bHW28FU=; b=kkHQHG0OEvidAmrkAymxeCC15/kLp5XDKaiJBks8XPeY85WeOFZeFm/NF0X5sXkYU3 gWA4MuSQxjDW9IcwuU/gRRwS/n7z8nc1OoKUUV1L36iD971fSj2mOQrg629PQ7Wny3wJ H0CcRpqYchzhfbnVhFzJmJGIxy8glmtOlwcfIXRipaYMhkwvGtVwoLg8YnAhCd/6Mrni WZmarl+YNxBPQYV5lMR34TapY7e5BH2NLWFComBz6Kg84fPE+bEYoIFycJ7uaGYgB936 HhpsSBIHZUWa2Q+yQboM0LzJniLguH0VboYsDsZ6PxQ56GJl6RpSGVFMzyWH2NmqtTBN tOog== MIME-Version: 1.0 X-Received: by 10.60.233.132 with SMTP id tw4mr49442785oec.35.1451721138585; Fri, 01 Jan 2016 23:52:18 -0800 (PST) In-Reply-To: References: Date: Sat, 2 Jan 2016 07:52:18 +0000 Message-ID: Subject: Re: [geda-user] Merging stuff. How to make it happen From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=001a1136b270c747bf0528552ad9 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 --001a1136b270c747bf0528552ad9 Content-Type: text/plain; charset=UTF-8 Hi Britton, I've been looking at some of your branches, (a quick look at least), and would like to do a more in depth review. Any objections to that before merging? I can try to find some time tomorrow if your about. Would appreciate a second pair of eyes on some of my stuff too, in the not yo distant future. Best wishes, Peter On 2 Jan 2016 02:32, "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" wrote: > > 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 > --001a1136b270c747bf0528552ad9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Britton,

I've been looking at some of your branches, (a quick loo= k at least), and would like to do a more in depth review.

Any objections to that before merging? I can try to find som= e time tomorrow if your about.

Would appreciate a second pair of eyes on some of my stuff t= oo, in the not yo distant future.

Best wishes,

Peter

On 2 Jan 2016 02:32, "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <<= a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com> wrote= :
<= br>
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.<= /div>

I stopped by the last sprint briefly and asked abo= ut this.=C2=A0 It sounds like there's no definite policy for deciding w= hen to merge things.=C2=A0 I therefore propose that the following condition= s should always be considered sufficient for a merge into the main devel br= anch:

=C2=A0 * the person who wrote it says it'= ;s ready
=C2=A0 * at least one other person has looked at the pat= ch
=C2=A0 * devel fixed or addressed any issues raised
= =C2=A0 * it doesn't remove any functionality
=C2=A0 * it does= n't do anything known to be contentious

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

Britton<= /div>
--001a1136b270c747bf0528552ad9--