Re: FreeBSD's problems as seen by the BSDForen.de community

Dominic Fandrey wrote:
> Hello,
> 
> I'm writing this mail on behalf of the largest German BSD community
> (http://bsdforen.de/). Some of our most respected and experienced community
> members have stopped using FreeBSD entirely, especially professional users
> have taken this step.
> 
> Many of us are very attached to FreeBSD and those of us who turn our backs to
> the system consider this a personal loss.
> 
> This mail is the result of a forum thread that consists of more than 200 posts
> (still growing) that started in October 2007
> (http://www.bsdforen.de/showthread.php?t=19426). It is meant to sum up the
> causes of this development, the reasons we see for this and what we think
> might be promising ways to try solve these problems; at least in the areas we
> were able to achieve consent.
> 
> The first problem is the unbearable performance many AMD users are suffering
> for several chipset and CPU generations. Even minimal I/O load on a hard disk
> suffices to lock up whole systems. Posts on the mailinglists current and
> stable have often been answered with denial or have simply been ignored. Only
> on very rare occasions (if at all) have these problems been taken seriously.
> 
> The second big problem is the handling of regressions. PRs remain unanswered
> or the reporters are told that the regressions they report do not exist. Some
> of our members have even suffered the experience that they developed a patch,
> but it simply was ignored or turned down for the reason that it was a "Linux
> solution". Especially frustrating for those among us who have never looked at
> Linux code.
> 
> These problems seem to be exceptions, but they are very persistent exceptions.
>  Problems concerning code that is currently being worked on are shown much
> attention, feedback and patches are happily taken and the developers supply
> the problem reporter with steps to take in order to track down these problems.
> 
> The problem seems, in our opinion, to reside with unmaintained code. It seems
> that nobody wants to take responsibility for code that has been untouched for
> a longer period of time. This is quite understandable, considering that
> developers already have projects they're working on and probably consider much
> more important, but that does not make it less of a problem.
> 
> What we think might be a solution to the regression problem, would be the
> establishing of a Regressions Team, similar to other teams like the Security
> Team. The sole purpose of this team would be to take care of regressions that
> concern unmaintained code.
> 
> To solve the performance problems it appears to us, that a guide to tracking
> performance problems or a performance test suite is required. This would
> hopefully allow us to write PRs and emails that would be taken more seriously.
> 
> - Dominic Fandrey on behalf of BSDForen.de community

Thanks for the feedback.  It is hard to respond to the reports of poor 
performance or other problems without specific information though.

I know from my own experience trying to investigate some of these 
performance issues that come up from time to time, that it is often very 
hard to get submitters to report sufficient information to understand a 
problem, even when they are pointed at documentation explaining the 
required steps in detail.  However, we are in the process of introducing 
changes to the debugging tools to make this process easier; textdumps 
and DDB scripting will allow the most common debugging data to be 
collected in a more automated manner, reducing the need for user 
interaction.

Another factor is that many of these issues are hardware dependent, and 
unless developers have access to the exact model and configuration of 
hardware (and/or the relevant hardware datasheets and errata) they are 
often impossible to replicate or understand.

That being said, I do think we could do more to identify and track 
regressions as they occur, so this is definitely something we should 
think about in more depth.  More importantly, members of the community 
are encouraged to come forward and help out with the task of maintaining 
older code.  As you say, this often becomes neglected simply because 
there are never enough developers to go around.

Best wishes,
Kris