Re: Heavy I/O blocks FreeBSD box for several seconds

On (11/07/2011 16:36), mdf_at_FreeBSD.org wrote:
> On Mon, Jul 11, 2011 at 4:00 PM, Ali Mashtizadeh <mashtizadeh_at_gmail.com> wrote:
> > Maybe someone can setup something like reviewboard [1] for developers
> > to use. This may also help folks who want to keep abreast of the
> > current work in a particular subsystem or get involved into the
> > development process more. At my company we use reviews and it seems to
> > help the catch some bugs and help new engineers ramp up faster.
> >
> > [1] http://www.reviewboard.org/
> 
> FreeBSD development is completely open; anyone can sign up for the
> svn-src-* mailing list they are interested in, including
> svn-src-head_at_.  Code reviews are plenty as well; just check the list
> archives for discussion of bugs, poor design choices and unintended
> effects.  But most reviews are silent and after-the-fact by looking at
> the list mail.  It's a system that seems to be working just fine for
> the FreeBSD project so far.  This isn't a job for most anyone; it's a
> volunteer project and so anything that raises the barrier to getting
> work done for the project should be looked at with skepticism.

I agree with everything said above and think that it's not reviews
that's missing. By review I don't mean something like getting "ok to
commit" reply from N developers before committing. svn-src_at_ works
great for it, commits keep getting reverted :) Review is a time
consuming process that also requires certain level of expertise.
Volunteer project can hardly afford it.

Having a project adopted way of sharing work in progress will be a step
forward. Yes, I'm aware of perforce, it's to hard to use and wasn't
designed to share and test ideas. I think guthub can be a very good
candidate (but AFAIK it won't allow hosting of FreeBSD repo for not paid
accounts). I'm not suggesting switching to git as VCS, but using github
UI for communication and tracking not yet commited or work in progress
changes. In ideal world developers will merge patches from each other
increasing chance of a good code to survive and get commited later.
Currently we have patches hosted at people.freebsd.org, as attachments
on maillists and PRs -- almost all stale or outdated. Key difference of
github is that original patch author will be aware of you using it,
potentially updating and improving it. Others can continue supporting
the patch if original author abandons it, etc. Sending patches is too
complicated and counterproductive comparing to github.

Thanks,
Gleb.

> 
> Is there a specific deficit that you want to address?
> 
> Thanks,
> matthew