Date: Fri, 20 Jan 2012 21:25:21 +0000 From: Chris <chrcoluk@gmail.com> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-hackers@freebsd.org, WBentley@futurecis.com, Robert Watson <rwatson@freebsd.org>, Andriy Gapon <avg@freebsd.org>, William Bentley <William@futurecis.com> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <CAOhm=5q_z7uYK2k4smcOwTOfdp__2ioVYozz617uorLxxW8ymw@mail.gmail.com> In-Reply-To: <Pine.GSO.4.64.1201181147450.6287@sea.ntplx.net> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <1326756727.23485.10.camel@Arawn> <4F14BAA7.9070707@freebsd.org> <alpine.BSF.2.00.1201181034580.51158@fledge.watson.org> <4F16A5B8.2080903@FreeBSD.org> <Pine.GSO.4.64.1201181147450.6287@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 January 2012 17:13, Daniel Eischen <deischen@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOhm=5q_z7uYK2k4smcOwTOfdp__2ioVYozz617uorLxxW8ymw>