Mail Archives: geda-user/2016/01/21/00:18:05

X-Authentication-Warning: 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;; s=20120113;
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820;
X-Gm-Message-State: AG10YOTKiDN7cve8CAW7FWmnXo1TBgD1rf301k3wPZbnIgIT9Sv+1Wcb3ne3a58JR0/lGsHoDXG/YJ/3rUEdvA==
MIME-Version: 1.0
X-Received: by with SMTP id c5mr28041436wja.88.1453353379501;
Wed, 20 Jan 2016 21:16:19 -0800 (PST)
In-Reply-To: <>
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>
Date: Thu, 21 Jan 2016 08:16:19 +0300
Message-ID: <>
Subject: Re: [geda-user] Project leadership
From: "Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: 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

On 1/20/16, DJ Delorie <dj AT delorie DOT com> wrote:
>> 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.
> True, but there's a wide range of options (and paranoia levels)
> between "good enough to play with" and "good enough to release".
> 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.

Main rules I use for myself are:
 - don't commit code which obviously has serious bugs or crashes;
 - if I have inadvertently commited something like this, either
   fix or revert it ASAP;
 - 'make distcheck' must always work; if it doesn't work, fix it.

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019