From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 14 15:54:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3459D106566C; Thu, 14 Jun 2012 15:54:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BFC388FC0A; Thu, 14 Jun 2012 15:54:51 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5EFsm4P006923; Thu, 14 Jun 2012 18:54:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5EFsm8m045760; Thu, 14 Jun 2012 18:54:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5EFslvT045759; Thu, 14 Jun 2012 18:54:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Jun 2012 18:54:47 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120614155447.GC2337@deviant.kiev.zoral.com.ua> References: <20120614042602.GA6638@lonesome.com> <201206140820.02798.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CFO0SFgG+t1lcV5s" Content-Disposition: inline In-Reply-To: <201206140820.02798.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Garrett Cooper , Mark Linimon , Adrian Chadd , Matt Olander , freebsd-hackers@freebsd.org Subject: Re: Upcoming release schedule - 8.4 ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:54:52 -0000 --CFO0SFgG+t1lcV5s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 14, 2012 at 08:20:02AM -0400, John Baldwin wrote: > On Thursday, June 14, 2012 12:30:19 am Adrian Chadd wrote: > > On 13 June 2012 21:26, Mark Linimon wrote: > > > On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: > > >> The only way that this would really work is if there were dedicated > > >> sustaining engineers working on actively backporting code, testing i= t, > > >> committing it, etc. > > > > > > I'm going to agree with Garrett here. IMHO we've reached (or surpass= ed) > > > the limit of what is reasonable to ask volunteers to commit their spa= re > > > time to. This is doubly true when we have more than one "stable" bra= nch. > >=20 > > I totally concur. >=20 > This is why I think we need fewer branches so that there is less merging = to=20 > do. Even in the bad old 4.x days developers would merge things (especial= ly > driver updates) from HEAD back to 4.x. If we move X.0 releases farther > apart then developers will still MFC things, the issue is that they don't > want to MFC to 2 stable branches. I do not find it cumbersome to merge to two branches. What I find quite demotivating is the conflicts and drifted KPI/API. So my usual reaction to the attempt to merge to stable/8 which fails due to conflicts is just remove the MFC reminder. I do sometimes reconsider the choice if explicitely asked by somebody, but I really prefer to not do risky commits to old and presumably stable branches. I do not have much incentive to merge to 8 anyway, except a warm feeling of providing some relief to a peer. So having long-living stable/8 and not having stable/9 means not doing some merges at all, instead of doing just one merge. YMMV. --CFO0SFgG+t1lcV5s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/aCUcACgkQC3+MBN1Mb4jzWACeLpaJcS+tVzkKTZKoLS2CmguT gWIAoOCeRDwOsXtaDppG3/rbt/psU886 =hqj+ -----END PGP SIGNATURE----- --CFO0SFgG+t1lcV5s--