In this Edition:
* Letter From the President
* 2009 Fundraising Drive
* Dru Lavigne Helping Foundation
* Safe Removal of Active Disk Devices
* Wireless Mesh Support
* Improvements to the FreeBSD TCP Stack
* AVR32 Support
* Problem Reporting Prototype
* FreeBSD Powers Long Distance Wireless Link
* DCBSDCon 2009
* AsiaBSDCon 2009
* Foundation at BSDCan and Developer Recognition
* 2009 Grant and Travel Grant Recipients
* BSDCan Spotlight
* Financials
Tuesday, July 28, 2009
Hot off the Press: FreeBSD Foundation Newsletter
Subscribe to:
Post Comments (Atom)
I am a FreeBSD of many many years, but this foundation newsletter made me chuckle. Justin Gibbs talks about how fabulous the FreeBSD communication ecosystem is, yet that is exactly where FreeBSD fails. There are a large number of very talented people working on FreeBSD, but so many of the processes are inscrutable from the outside. Here are a few examples:
ReplyDelete* The release process for 8.0 (and 7.2 before it) is mysterious and hidden. Although dates are announced in advance, they are never adhered to and weeks go by without the slightest mention of what is causing the delay or what to expect as the next steps. For those of us who are testing new systems and reporting feedback this is very frustrating. Will there be another beta? What things are causing the holdup? Will certain reported issues be addressed?
* I suspect there are other private mailing lists where these things are being discussed: only a small amount of developer interaction occurs on the public stable/current/etc mailing lists. Or perhaps most communication happens via IRC/chat. If that is the case, it makes the development process part of an "in" club which is hard to access from the outside.
* As an example of this is the distinction between private perforce repositories and the public svn. There are no sandbox areas in svn, no branches for experiemental development. Much of the new work is hidden in P4 until it is ready to be unveiled as a complete work.
* Part of the frustration around the development process is the bug tracker. Some months ago I volunteered my services to Mark Linimon to assist with that process and got no response. I assume that there have been a series of private conversations (not on the public mailing lists) about his being funded to develop a new bug tracker from scratch. But I would have hoped that the community as a whole might have been asked what sort of things they would like to see in a bug tracker. Unless the 'community' who talk about those things are a core team communicating in private channels, I don't think there is any visibility of that. Those of us who might be able to help in some way are unable to see what is happening, what has been decided and what direction things are headed.
I'd love to know the rationale for funding yet another bug tracker to add to this world (perhaps there are some very specific things it has to do, but I can't imagine what). I'd love to know why the project is delayed several months. Is there a scoping document somewhere? I am sure Mark is very busy and it is just delayed through lack of time, but my point is about the public visibility of these things.
Again, let me reiterate, the project is amazing and the results excellent. The people are dedicated and talented. But the communication sucks. Compared for instance to the Apache project where all developer conversation happens in the public unless there is good reason, FreeBSD is very obscure. The FreeBSD Foundation is looking for donations, but I'd not donate to an organisation that chooses how to spend its money in secret, has no publicly visible process for submissions and choosing between them.
Finally, I think the core of better communication will be a new bug tracker. One that ties tasks to releases and svn. One that gets communication out of mailing lists and IRC/chat and into the comments against a task. I have great hopes that will come about soon.
@ari:
ReplyDeleteThanks for the useful feedback!
Hi ari:
ReplyDeleteThe FreeBSD release engineering team is well aware that it needs to improve its communications. This is also a problem of communications within the project, not just between the project and the outside world. We're currently experimenting a bit, and have recently been maintaining a wiki page tracking the release and work queue, which has been pointed to in a number of our status updates to the current mailing list:
http://wiki.FreeBSD.org/8.0TODO
I think this addresses some, but not all, of your concerns. What needs to happen next is that changes to this information (such as the short status note at the top) need to be more regularly posted in a form that can be followed by the public.
BTW, in response to another portion of your comment -- you'll notice that there now are both "projects" and "user" areas of svn.FreeBSD.org that are increasingly seeing use for project work instead of Perforce.
ReplyDeleteHowever, Perforce continues to provide a better tool for some project work (it provides extremely powerful merge support). You can monitor work there using the public perforce reviews mailing list and the perforce.FreeBSD.org source code/log browsing web site. I would agree that this is not as convenient as, say, a public Subversion repository. However, where projects have been extremely long-running, we've provided cvsup exports of their Perforce work areas -- for example, the TrustedBSD work is developed in P4, but you can check out each of the work areas using cvsup.
Without further improvements to Subversion as a tool, I don't think we will see all project work move out of Perforce, although we will see an increasing proportion done in Subversion. Primarily, Subversion's weaknesses lie in efficient management of project branches through stateful and bidirectional merging. These are problem areas that the Subversion project is actively working on, and 1.5 represented a significant step forward (just not there yet).