From owner-freebsd-arch@freebsd.org Fri Dec 29 23:10:04 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56BC3EB5422 for ; Fri, 29 Dec 2017 23:10:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 40DA68015C for ; Fri, 29 Dec 2017 23:10:04 +0000 (UTC) (envelope-from bright@mu.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3C7D2EB5421; Fri, 29 Dec 2017 23:10:04 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BFB2EB5420 for ; Fri, 29 Dec 2017 23:10:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (smtp.mu.org [IPv6:2001:559:9c:200::ffff]) by mx1.freebsd.org (Postfix) with ESMTP id 28F828015B for ; Fri, 29 Dec 2017 23:10:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MBP-2.lan (c-67-169-71-186.hsd1.ca.comcast.net [67.169.71.186]) by elvis.mu.org (Postfix) with ESMTPSA id D0D3710C308A; Fri, 29 Dec 2017 15:09:57 -0800 (PST) Subject: Re: bitrot [was: Deprecating / Removing floppy drive support] To: Mark Linimon , "Rodney W. Grimes" Cc: Hans Petter Selasky , Eitan Adler , "freebsd-arch@freebsd.org" References: <43746890-e60a-5c8f-4c77-bbfe9a5a6aa9@selasky.org> <201712031655.vB3GtIME041023@pdx.rh.CN85.dnsmgr.net> <20171203172755.GA4210@lonesome.com> From: Alfred Perlstein Message-ID: <869828cb-e4e2-78fb-84ba-5d0ec8e919b9@mu.org> Date: Fri, 29 Dec 2017 15:09:57 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171203172755.GA4210@lonesome.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 23:10:04 -0000 On 12/3/17 9:27 AM, Mark Linimon wrote: > On Sun, Dec 03, 2017 at 08:55:18AM -0800, Rodney W. Grimes wrote: >> my observation is that FreeBSD is a lot of new toys that work fairly >> well and a collection of rotting bits that get the axe every few >> years. > Having spent 10+ years triaging PRs I can tell you for certain that > there are large parts of the src tree* that no one works on. (For > instance, if we use "bin" as a rough proxy for "userland", there are > 1668 userland PRs.) > > I had a breakdown of kern PRs into "subsystems" which I kept going for > a few years, but it bitrotted (was GNATS-specific). It never really > got any uptake, but I found it educational anyways: > > https://people.freebsd.org/~linimon/studies/prs/prs_for_all_groups.html > > For instance, it led me to believe that large chunks of "libraries" and > "audio" were not actively maintained. > > But beside from features missing from the tools, we have a large, open, > problem with "someone needs to take ownership of the xyz code". > > I would be happy to hear constructive ideas. (Readers should be warned > that based on past experience I no longer believe that "well, someone > should just do that" leads anywhere.) > > obdisclaimer: I am not trying to discourage the people who currently > actively work on maintenance by pointing to the overall numbers; in fact, > I appreciate their efforts. I just want to know how we can clone them. > > mcl > > * The ports tree does a little better by assigning maintainers. It > turns out that most, but not all, of the key components have at least > a putative maintainer listed. It's good but insufficient. > I understand how frustrated folks can be that there are PRs, quite a few with patches, out there that are not being addressed or merged. That said, accessibility is always going to gate contributions and engagement of users. Accessibility can be fixed by a number means: 1) reduce the test / compile cycle. 2) replacing obsolete or seldom used tooling with modern industry standard tooling. 3) lowering the barrier to entry. 4) giving contributors an experience that prepares them for cross functional work. These really are all actually a single point that one should focus on. If a project decides to use a bag of tools that is extremely specific to itself or not widely used anymore it really has only itself to blame for lack of participation of its users.  It is up the project to realize that its infra is lagging behind the industry and work towards bringing it in line with the previous stated accessibility fixes to bring in new and engaged folks interested in work as well as keep its current base of workers interested in continuing to work. -Alfred