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

On Jan 10, 2008 12:58 PM, Eric Anderson <anderson_at_freebsd.org> wrote:
>
> Mark Linimon wrote:
> > I appreciate the fact that you took the time to write this post and
> > raise serious issues in a non-confrontational manner.
> >
> > On Thu, Jan 10, 2008 at 12:20:13AM +0100, Dominic Fandrey wrote:
> >> 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.
> >
> > The responses on the mailing lists can indeed vary in quality.  My own
> > experience is that many of the key FreeBSD developers respond fairly
> > well -- when they've got time to do so.  Some exceptions exist.  But
> > I don't think any one person is working on amd64 to the exclusion of i386.
> > Perhaps that is what it would take.
> >
> > Other than trying to identify individuals whose responses are doing more
> > harm than good, I don't have any suggestions here.
> >
> >> 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.
> >
> > Unfortunately it requires volunteers to constitute such a thing.  I've
> > been trying to come up with ideas on how to get more people involved
> > in what we would consider 'maintainence' activities, but I've yet to
> > make an impact.  A few people have expressed interest in helping to go
> > through the PR backlog, but the big shortage is committers who are
> > willing to work with them on such unglamorous tasks.  (I am working on
> > a proposal to at least make it less frustrating to do so, but I don't
> > want to tie that into this thread.)
> >
> > Having said that, I would join such a team and try to work with it.
> >
> >> PRs remain unanswered or the reporters are told that the regressions
> >> they report do not exist.
> >
> > We clearly have a disconnect on PRs.  More come in than we have any way
> > to handle.  This is clearly most distressing when the PRs contain
> > patches and/or test cases.  Again, I'm open to ideas on how to set up
> > something where more people can participate.
> >
> > I've tried to flag certain PRs with '(regression)', fwiw, which is
> > necessary but clearly insufficient.
> >
> >> To solve the performance problems it appears to us, that a guide to
> >> tracking performance problems or a performance test suite is required.
> >
> > I think that's 2 separate issues.  I had not thought much about trying
> > to categorize certain PRs as 'performance' but it really does make sense.
> > I will try to work on this issue.
> >
> > There is actually work on performance tests, but it goes on behind the
> > scenes and is not publicized.  (The jump in performance for most
> > workloads on i386-7 is due to the efforts of many individuals who have
> > been relentlessly testing MySQL, Postgres, Bind, and other real-world
> > workloads since the 7 branch was created.  Kris, the other respondent in
> > this thread, is one of the people doing a great deal of work on this.)
> > Some of this is documented at http://wiki.freebsd.org/Performance.  If
> > there's more specific information that needs to be added there, let me
> > know off-list.
> >
> > There is also the work at http://wiki.freebsd.org/PerformanceTracker,
> > which I do not know the state of.  This sounds encouraging.
> >
> > FreeBSD is mostly driven by individual efforts (we are, however, seeing
> > more interest from corporations, some of whom see network performance
> > as a key issue).  To some extent it's more "interesting" to do new work
> > than do maintainance work; this is a classical software engineering
> > problem.  Again, I'm completely open to suggestions on how to get more
> > people interested in working in this area.
>
> I'd like to suggest that there are a lot of people there are not
> committers, yet would like to help.  Most times they are told to 'look
> at the PR database' - and while that is of course a direction to point
> them, I would recommend instead changing the current methods a bit.
> Most not-yet-committers have interests in a certain area of FreeBSD, and
> maybe they have experience there too.  Instead of the path being
> something like:
> - look at PR's, make patches, submit patches
> - After enough time, someone offers a commit bit
> - Once commit bit is accepted, get a mentor
> - Work under mentor for awhile
> - released from mentorship
>
> Make it more like:
> - Interested developer wants to help with FreeBSD in a particular area
> of his/her expertise or liking
> - A current FreeBSD committer for that area mentors the developer,
> suggesting PR's to look at, patches to test, projects to work on, and
> reviewing their patches.
> - The current committer also does the committing of any patches needed.
> - Once the new developer has shown 'goodness', the regular commit bit
> path is followed.
>
> The main difference is that a developer is given a 'mentor' very early,
> with guidance and a little hand holding in the beginning.  This would
> remove the 'wandering developer' problem (where a new developer seems to
> wander around looking for a simple bug to fix, or patch to try, not sure
> the best way to go about it, etc), and allow the mentor to focus the new
> developer on a task that may be important to the project (fixing an old
> bug, testing out a rotting patch, etc).  A lot of times the new
> developer does not know who to talk to for simple project related
> questions, and while asking on the lists usually does end up yielding
> results, I bet that most don't ask the question because it is simply
> more daunting than either just eventually figuring it out on their own
> or (if they had the option) asking a 'mentor' the question directly.
> Also, when someone feels they have some responsibility for an area of
> the code, they are more likely to respond to issues in it, and be proud
> of keeping it current.

I like this approach but it can be humanly impossible. Ok, not
impossible but difficult.
The small amount of developers all claim of the very little time they
have to give to the project. Now imagine babysitting everyone that
wants/needs attention. Of course, getting more people onboard would
relieve the "small amount of developers" pressure but then again, I
prefer quality over quantity.
This kind of problem has risen recently on usb_at_ and something
definitly needs to be done, with the risk of FreeBSD being a
contributor based project, becoming a "it's too hard to contribute
project". This will alienate (more) people as they loose the feeling
of connection to the project.
I would welcome this suggestion as long as it is sustainable by the
developers. Actually it's theirs to welcome or not;-)

> Also - a really good (up to date) guide on setting up a nice development
> environment would probably help huge amounts.  I know there are many
> different environments, but that's great - we should write them all up.
>   That would get more developers up-and-running quicker.

This would be *MOST* welcome :-D

>
> Just my $0.02
>
> Eric
>

++karma on your $0.02

-- 
Joao Barros