X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Date:	Thu, 21 Jan 2016 22:46:19 -0500
From:	al davis <ad252 AT freeelectron DOT net>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] Project leadership
Message-ID:	<20160121224619.44f0fb5e@floyd.freeelectron.net>
In-Reply-To:	<201601201958.u0KJwPbo029901@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>
	<CAJXU7q_cvMt2gTBc0jm6+42wLC7O-iKz7PcVkkMsjAw7b8SAmw AT mail DOT gmail DOT com>
	<201601201958 DOT u0KJwPbo029901 AT envy DOT delorie DOT com>
X-Mailer:	Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version:	1.0
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

On Wed, 20 Jan 2016 14:58:25 -0500
DJ Delorie <dj AT delorie DOT com> wrote:

> What I don't want is to make it so difficult and/or expensive to get
> work into master, that work never gets into master.  We need to be
> willing to accept *some* risk in order to promote progress.

I still think the way to do it is with feature branches and an
"unstable" branch.

Make it work in the feature branch (name your feature) that is kept up
to the latest unstable until it is merged .. then ask the question "is
this ready???" Then when it is, merge to unstable, which should be a
simple merge, probably a "fast-forward" merge where it becomes the
unstable branch.

Then let it cook for a few weeks.  When unstable is stable, it becomes
master.


The delay getting into master happens when the contributor of the new
code lets it sit unfinished or with known bugs.  If this code were
merged to master, maybe it would never get fixed, maybe somebody else
would get annoyed enough with it to fix it.

Do these premature merges often over many years, it ends up a big mess,
and "bug squashing" becomes the hot thing to do in code sprints.  With
a little more testing up front, the original contributor should fix his
own bugs before moving on, and code sprints can focus on adding new
functionality.  Chasing pointer bugs in somebody elses code is not my
idea of fun, but I have some procedures for doing it that really work.

So take your pick, but know what you are choosing.

- Raw text -