On 18 January 2012 17:13, Daniel Eischen <deisc...@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. Regardless 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. One known problem is using >>> a >>> single "head" release engineer in steering all releases. I think this is >>> a >>> mistake, as it makes the whole project's release schedule subject to >>> individual >>> unavailability, burnout, etc, as well as increasing the risks associated >>> with >>> low bus factor. I'd like to see us move to a model where new release >>> engineers >>> are mentored in from the developer community for point releases, ensuring >>> 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. The role of the "head" release engineer >>> shouldn't be >>> hands-on prodution of every release, but rather, steering of the overall >>> team. >>> >>> I'd like to see this begin with 8.3, drawing a per-release lead from the >>> developer community, and continue with a fixed schedule release of 8.4. >>> Yes, >>> 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 useful >> to >> have some sort of branch meisters. The current model when every developer >> decides whether and when and where to do an MFC does not seem to be the >> proper >> one. Developers often forget to do an MFC. Or decide against an MFC when >> there >> is no reason to do so. Or 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. Keep -current at N for a while, prohibiting > ABI changes, and any other risky changes. If 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. Maybe 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-unsubscr...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
