From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 20 21:56:03 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDEE41065674; Fri, 20 Jan 2012 21:56:03 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA3F8FC0C; Fri, 20 Jan 2012 21:56:03 +0000 (UTC) Received: by iagz16 with SMTP id z16so2237545iag.13 for ; Fri, 20 Jan 2012 13:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dB8fpsWHStyUyzP5wLjOYwULqDQmrKqCAEIBKndRGkM=; b=j8YhPjCl3y6GY5G6bmc1ZqyzZyPpAys4TXlk0hVKlgnx+Vjne5vCe75bcAxZ/7cDjJ 8YIl4GuBajzFjDmAcicsM2pyX5aGQ1q/NmNLDE20HBHxMbjF2dDnlmDaVU3VE2FMMhPS /vh/AyFRckaBFa/nwgLB4kUKx7CW6jthh2cSM= Received: by 10.50.168.4 with SMTP id zs4mr140428igb.25.1327094742144; Fri, 20 Jan 2012 13:25:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.53.199 with HTTP; Fri, 20 Jan 2012 13:25:21 -0800 (PST) In-Reply-To: References: <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <4F16A5B8.2080903@FreeBSD.org> From: Chris Date: Fri, 20 Jan 2012 21:25:21 +0000 Message-ID: To: Daniel Eischen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 20 Jan 2012 22:03:55 +0000 Cc: freebsd-hackers@freebsd.org, WBentley@futurecis.com, Robert Watson , Andriy Gapon , William Bentley Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle 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: Fri, 20 Jan 2012 21:56:04 -0000 On 18 January 2012 17:13, Daniel Eischen wrote: > On Wed, 18 Jan 2012, Andriy Gapon wrote: > >> on 18/01/2012 12:44 Robert Watson said the following: >> >>> My view is therefore that we have a "social" -- which is to say >>> structural -- >>> problem. =A0Regardless of ".0" releases, we should be forcing out minor >>> releases, >>> which are morally similar to "service packs" in the vocabulary of other >>> vendors: >>> device driver improvements, new CPU support, steady of conservative >>> feature >>> development, etc, required to keep older major releases viable on >>> contemporary >>> hardware and with contemporary applications. =A0One known problem is us= ing >>> a >>> single "head" release engineer in steering all releases. I think this i= s >>> a >>> mistake, as it makes the whole project's release schedule subject to >>> individual >>> unavailability, burnout, etc, as well as increasing the risks associate= d >>> with >>> low bus factor. =A0I'd like to see us move to a model where new release >>> engineers >>> are mentored in from the developer community for point releases, ensuri= ng >>> that >>> we increase our expertise, share knowledge about release engineering in >>> the >>> broader community, and get new eyes on the process which can lead more >>> readily >>> to process improvements. =A0The role of the "head" release engineer >>> shouldn't be >>> hands-on prodution of every release, but rather, steering of the overal= l >>> team. >>> >>> I'd like to see this begin with 8.3, drawing a per-release lead from th= e >>> developer community, and continue with a fixed schedule release of 8.4. >>> =A0Yes, >>> more staffing is needed, but first, what is needed is an improvement in >>> model. >> >> >> Robert, >> >> I think that in addition to what you suggest above it would also be usef= ul >> to >> have some sort of branch meisters. =A0The current model when every devel= oper >> decides whether and when and where to do an MFC does not seem to be the >> proper >> one. =A0Developers often forget to do an MFC. =A0Or decide against an MF= C when >> there >> is no reason to do so. =A0Or sometimes do an MFC where the stable branch >> users >> would rather prefer that it is not done. >> There needs to be someone who "owns" a branch and who want to make it >> perfect. >> Someone who could request an MFC (or even do it himself) and someone who >> could >> reject an MFC. > > > "someone who owns a branch..." - If you cut release N.0, do not > move -current to N+1. =A0Keep -current at N for a while, prohibiting > ABI changes, and any other risky changes. =A0If a developer wants to > do possibly disruptive work, they can do it from their own repo. > At this point, the branch meister(s) own the branch, and HEAD is > only moved to N+1 when they decide that the branch is stable > enough for production. =A0Maybe then, N.1 (or N.2) is rolled out. > > I think most developers track HEAD because: you have to commit and > test in HEAD before MFC'ing anyway; because of that, it easier > to track and test one branch; and ports built for HEAD may not > work on -stable. > > -- > DE > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " Interesting conversation, what you just siggested I suggested years back ;) My view is a branch cant be marked stable at .0 because it hasnt had enough= use. In addition I feel PRs need more attention and I would accept less frequent release in trade for more fixed bugs. I am about to post some PRs myself, one been a nasty lockf issue which has forced me to shift about 20 production http servers over to debian because of processes going into lockf (at low/moderate loads). Chris