Date: Sat, 16 Feb 2002 02:38:56 -0800 From: Mike Makonnen <mike_makonnen@yahoo.com> To: Kamal Prasad <kamalpr@yahoo.com> Cc: freebsd-questions@freebsd.org Subject: Re: contributing to freebsd Message-ID: <1013855936.58520.17.camel@blackbox.pacbell.net> In-Reply-To: <20020216062611.53860.qmail@web13504.mail.yahoo.com> References: <20020216062611.53860.qmail@web13504.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2002-02-15 at 22:26, Kamal Prasad wrote: > Hi! > Im an engineer working in bay area. Ive been working > as a white box test engr for the unix (freebsd based) > kernel for the past couple of years and have a good > understanding of how it works. Ive also attended a > class on FreeBSd kernel implementation by McKuisick. > I am interested in contributing to FreeBSD and would > like to know how to do so. > I look fwd to hearing from you. > thanks > -kamal Hi, After a couple of years of trying out various unix solutions I decided I liked FreeBSD best, and just recently decided to contribute some code as well. One thing I've learned, from following these lists and reading answers to questions like yours, is that no one is going to tell or ask you to do anything. *You* have to pick something that interests you, work on it, ask questions if you need help (in this regard I've found FreeBSD hackers to be quite helpful if you have a good idea of what you want to achieve and have specific questions), and submit it to the community. A good place to start is by browsing the PRs. If you're interested in joining a pre-existing project there's a bi-monthly Developer Status Report with most, if not all, the current projects and their status. Here's a couple of things I've found to be very helpful: - subscribe to cvs-all: This list keeps you up to date on all changes to the source tree. The log messages can be very helpful in explaining bits and pieces of the huge amount of code in the project. The comments of other developers on the changes is also very helpful. The biggest benefit; however, is that it allows you to familiarize yourself with where things are in the source tree and it allows you to keep track of the current state of the source tree. It can be a little (OK... a lot) overwhelming because the commiters are very active. I use a procmail recipe to filter out ports,doc,sparc, and alpha commits since my main interest doesn't lie there. - subscribe to freebsd-bugs: This is a nice way to keep track of PRs as they come in. Every so often you will find a problem that interests you and that you have the necessary environment to reproduce. For example, there's a PR that involves burncd, audio files, and LG drives. I have an LG drive and I can reproduce the problem so I'm currently working on debugging it when I get some spare time. - maintain a local copy of the cvs repository: I can't stress this one enough. I found that NOT having a local copy was a major inconvenience. Among other things having a local copy will come in very handy when you want to check out specific revisions, generate patches, keep a record of your local changes, debug a problem a user is having on one of the Releases or branches, and countless other things. A copy of just the source tree is only about 1.5 Gigs (It will fit nicely, with room to spare on most current hard drives). - If I recall correctly Matt Dillon, Julian Elischer, and a couple of others have in the past posted messages regarding how you might want to setup your development environment. If you can find them, they're quite helpful. If I can find the copies I have sitting somewhere on this machine I'll send them to you. - Tracking the development branch, -CURRENT, is a good way of finding areas of the OS that need work. If you aren't afraid of getting your hands dirty and have a fall-back option (like -STABLE on another machine/partition) it isn't terribly unstable as a development platform. With some exceptions, when things break they get fixed pretty quickly. Besides, at the very least you can rebuild it every so often and let developers know when a commit has broken something. Also, despite what the handbook says, IMO -current *is* a great way of getting the latest and greatest features and playing with them before the rest of the guys on your block :-) Let me qualify that: tracking the development changes as a new feature gets added to and matures on -current is a good way of understanding how the new feature --and the system-- work. - The book "The Design and Implementation of the 4.4BSD Operating System" is very helpful in understanding the kernel. Much of it is still current. - The book "TCP/IP Illustrated" is a good place to look if you want to familiarize yourself with the network stack. The one thing that's probably guaranteed to make you give up is: - Thinking "I know! I'll just start at X and start reading the source code. Then I'll understand everything!" Anyways, as someone who just recently started out on the same adventure (and an exhilarating adventure it is), these are some of my thoughts on the subject, and I'm sure others will find other things to add to or comment on. cheers, mike makonnen P.S. - man(1) is your new bestest friend :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1013855936.58520.17.camel>