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=5uJlpXCqWBk5sl1sI9bo+12UJ7X75s+Bv5gK1/N4nwA=;
	b=fOnmSq61b/uO9eYpgWwz+KYMqs5z+BYInZz8HzaYIxEW9+1mfNLS2d7Bjo/GErJjDu
	6ATr8mGSe6cQ1Wvqr92KV0PUWkRohUVdfoXaAl1U8rVpkfaNLeW0E2W9AYSo8erQx2iO
	zdwLX67y2IXetwiDS3OZrxx6KUYZ3iTkPr1pzun23rJBqqOZ5U3ZZXRSc+mg5hPSHpAI
	xxe67xM/oOsrpk7H5oGkuQDyiIokzEYq4o43ltaNdTRhg1j/rkMDa2EX6IMsyh0VJ0G+
	2Yy1Wc7m/g8rVNNR4NGJksSlpqPhUIHqoqiR6lm5CnZMcKhhSEiSLXtrUuLxcleXI4uF
	ke/g==
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=5uJlpXCqWBk5sl1sI9bo+12UJ7X75s+Bv5gK1/N4nwA=;
	b=EIqwxWmSsRZgON194wzVjLPiTdT9PJCttEMl/Scp0g6ah2+fzHZxtEeXlGm7WXSlgu
	KCOZD+/Xkr2/7LmxgviCq8rsF9HIA5gsP2cbLlRgwGcD3quPcwbyQ36e9ibK9n2wqKq0
	lTg8mVfoQErBve3o3m/4JN60vE6aWtK9IvxMz/7HtF/yZgOAlgH585qvi2LqspKa7WTt
	QIE8YFRM/ZO0e9C1QnEvBPV2kjB+knXFIQFyd5AWEXBur0QrbLEh9eU2n4V8F4nIAmZ7
	l0fPwrxNBiBLbAwVk3vOg1lqObUyOP9irc7Upj0lng6Cvq7tjaw66MfPSHcTvR/yKSW5
	gWag==
X-Gm-Message-State:	ALoCoQniGE4kv16EiGu0fgZdB10f68S/pCWaZZMV4a/gkawiKwLqq+LoM8pda03z1LP7/ZryB8nkhGLGOnvOihnkrPMRptzIVg==
MIME-Version:	1.0
X-Received:	by 10.202.201.77 with SMTP id z74mr29212331oif.24.1453319590828;
	Wed, 20 Jan 2016 11:53:10 -0800 (PST)
In-Reply-To:	<201601201903.u0KJ3Lx4026878@envy.delorie.com>
References:	<20151222193859 DOT 26898 DOT qmail AT stuge DOT se>
	<20151223202851 DOT 637d5b1f AT jive DOT levalinux DOT org>
	<20151223195846 DOT 8392 DOT qmail AT stuge DOT se>
	<CAM2RGhS2bg=Rjuq6oEeOacV7PfUENy_jq7dxag=vWsUbdH6pAQ AT mail DOT gmail DOT com>
	<20151229155647 DOT GA3752 AT localhost DOT localdomain>
	<CAM2RGhSLND5+JSSj=1cUPUhzkTCK6d7NZ61QL-eViZRccY5LqA AT mail DOT gmail DOT com>
	<20151229175222 DOT GD3752 AT localhost DOT localdomain>
	<alpine DOT DEB DOT 2 DOT 11 DOT 1512311656190 DOT 1475 AT newt>
	<96A12FC1-E09C-4D63-8346-5A62FDAB4228 AT sbcglobal DOT net>
	<alpine DOT DEB DOT 2 DOT 11 DOT 1512311916190 DOT 12724 AT newt>
	<20160120173024 DOT GB16858 AT localhost DOT localdomain>
	<201601201903 DOT u0KJ3Lx4026878 AT envy DOT delorie DOT com>
Date:	Wed, 20 Jan 2016 19:53:10 +0000
Message-ID:	<CAJXU7q_cvMt2gTBc0jm6+42wLC7O-iKz7PcVkkMsjAw7b8SAmw@mail.gmail.com>
Subject:	Re: [geda-user] Project leadership
From:	"Peter Clifton (petercjclifton AT googlemail 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>
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

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

On 20 January 2016 at 19:03, DJ Delorie <dj AT delorie DOT com> wrote:

>
> On the PCB side we create a branch for each release, and those
> branches must always be "release ready" just in case, but not master.
> Master is where things come together, so we have to allow for some
> chaos.
>

That (IMO), doesn't mean "commit code which isn't ready", or "develop here"
like it was a CVS repository...

Clearly, master is always more likely to have bugs, as a result of
integration of new features (patch commit or merge - whatever), but I think
it is always best to TRY and keep master in a state where we expect it
works, and expect we COULD branch a release from it.

Peter

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 20 January 2016 at 19:03, DJ Delorie <span dir=3D"ltr">&lt;<a href=
=3D"mailto:dj AT delorie DOT com" target=3D"_blank">dj AT delorie DOT com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
</span>On the PCB side we create a branch for each release, and those<br>
branches must always be &quot;release ready&quot; just in case, but not mas=
ter.<br>
Master is where things come together, so we have to allow for some<br>
chaos.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">That (IMO), doesn&#=
39;t mean &quot;commit code which isn&#39;t ready&quot;, or &quot;develop h=
ere&quot; like it was a CVS repository...<br><br></div><div class=3D"gmail_=
extra">Clearly, master is always more likely to have bugs, as a result of i=
ntegration of new features (patch commit or merge - whatever), but I think =
it is always best to TRY and keep master in a state where we expect it work=
s, and expect we COULD branch a release from it.<br><br></div><div class=3D=
"gmail_extra">Peter<br></div><div class=3D"gmail_extra"><br><br></div></div=
>

--001a1134f920f4e1f00529c95582--

- Raw text -