bitrot [was: Deprecating / Removing floppy drive support]

[Alfred Perlstein]

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