Date: Sun, 09 Feb 2003 18:57:56 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Colin Percival <colin.percival@wadham.ox.ac.uk> Cc: Mark Murray <mark@grondar.org>, freebsd-chat@FreeBSD.ORG Subject: Re: Okay, I think I need some serious introduction ;-) Message-ID: <3E471534.901E75C1@mindspring.com> References: <Your message of "Sun, 09 Feb 2003 16:30:32 %2B0100." <Pine.WNT.4.51.0302091609570.2972@chasey> <5.0.2.1.1.20030209183111.03475ea8@popserver.sfu.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Colin Percival wrote: > At 18:16 09/02/2003 +0000, Mark Murray wrote: > >Use the OS. When something bothers you, fix it :-). Submit your fix > >back through the usual channels to learn the project norms and customs. > > Continuing on with this process, what's the next step? Specifically, > after finding a bug, fixing it, submitting a PR with included patches to > -CURRENT and -STABLE, and watching it sit in GNATS for 8 weeks, is there > anything to do other than keep on waiting? You can apply the patch locally, so you can continue finding more bugs and submitting more PRs. You can write regression tests that can prove whether or not your bug has been fixed, so that when the next release comes you, you can regress your list of bugs, and update the "Effects" field of the existing PRs, each time a -RELEASE happens. You can submit PRs containing your regression code, so that others can tell when the bug comes back, if it ever does, even after it has been fixed and marked closed. You can buy hardware that doesn't run under FreeBSD, and obtain the information from the manufacturer necessary to write a FreeBSD driver (this is often easier than obtaining information from FreeBSD on how to write a driver, with some kernel code being undocumented ;^)). You can buy hardware that doesn't run under FreeBSD, and for which the manufacturer refuses to provide information, and, if you live in certain countries, buy a copy of "Sourcer" from V Communications, Inc., and disassemble and reverse engineer the manufacturer's Windows driver, for compatability purposes, as allowed by law in those countries (e.g. Germany). If you live in one of those countries, you can probably get a lot of free hardware for the cost of shipping, from people who aren't in those countries, and found out that the manufacturer would not give you documentation, no matter how hard you pled (usually, a hell of a lot longer than just the 8 months you were complaining about 8^p). You can keep doing this until you get a "mentored commit bit", at which point you can vote for core team members, and project management. You can keep doing this with your "mentored commit bit" until you get a "real commit bit", at which point you will be permitted to perform small amounts of architectural work on your own, and you are still able to vote for core team members and project management. You can also request code by backed out, and the project by-laws require that it be backed out, unless it's a lot of code, in which case it stays, for fear of the backout and recommit process causing "repo bloat" (i.e. if the expectation is that it will be recommitted later, in some form, then your request will be denied as spurious, which it will be). You can get elected to core, and pretty much get away with significant architectural work, which no one else can get away with, as long as you do not step on the toes of other core team members. In other words, it's very much like going to work for an established company, and being hired in at the bottom rung as "customer support specialist", and having to work your way up. Does that answer your question? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E471534.901E75C1>