`busyboxvi` is not working like before

[John Spencer]

Laszlo Papp wrote:
> On Fri, Oct 31, 2014 at 6:11 PM, Laurent Bercot
> <ska-dietlibc at skarnet.org> wrote:
>> But when the problem is finding a maintainer with
>> enough time, expertise and willingness to maintain a project, forking is
>> definitely not a solution - on the contrary, it would only exacerbate the
>> problem. You were struggling to find one person, now you must find two.
> 
> Not quite, no. What I see is that Denis is the ultimate maintainer and
> *no one* else is allowed to commit changes from the contributors.
> 
> On the contrary, I have seen a *lot* of bikeshed on this mailing list
> about insignificant details. The end results usually were missing

what may seem like insignificant details to you is actually what busybox 
is about : providing a very small, nonbloated implementation of the 
standard command line utilities. if anything anybody wants gets 
merged/implemented, busybox turns into a second GNU coreutils.

> features due to completely irrelevant implementation details in my
> opinion. I still remember one of my first patches that got more than
> 100 emails in that thread and the whole thing was about bikeshedding,

yeah, that's what usually happens when certain people are involved in 
the discussion...

> again IMHO. Apparently, many people have resource for that, but not
> actual pragmaticism!

[ snip ]

> busybox --list | wc -l
> 351
> 
> Does anyone here really think that one person can maintain 351 applets
> alone? I think it should be acceptable for others to stand up and not

definitely. note that these applets are already complete and working.
denys did an excellent job in the past even though he has a dayjob that 
likely consumes the biggest part of his time.

> to have an exclusive person here responsible for everything. I am sure
> that there have been applet authors who would have been happy to give
> a helping hand with maintaining their code pieces.

"too many cooks spoil the brew".

my impression is that sw projects with a small number of maintainers 
work much better than those with a big number like KDE, where the left 
hand doesn't know what the right hand did:
the result is bloat (due to duplication and feature-creep), and bugs 
(due to insufficient review, and missing overview over the whole picture).

--JS