(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
On Fri, Oct 18, 2002 at 09:37:36AM -0700, Daniel Ng wrote:
> I am interested in helping with the development of
> Coda. How would I get involved? Who would I ask?
Posting to this list, or codalist_at_coda.cs.cmu.edu.
The most important thing is probably, getting the bugs out. My strategy is often,
1- Use Coda, find something that seems to be a problem.
(or look at reported problems http://www.coda.cs.cmu.edu/rt2/)
2- Find a way to easily reproduce the problem.
3- Figure out why this problem occurs. This is often the hardest part,
because it could be kernel, userspace, or a server problem. Or even worse a specific interaction between any of these.
Try conceptualize what really was intended to happen. For this I often fall back on the theses written by the students that worked on Coda. The underlying concepts and ideas are typically good. But manual pages, or looking what AFS2 or other network filesystems are doing is also helpful.
Steps 2 and 3 typically go hand in hand, in some cases it is hard to get a reproducible test without knowing what goes wrong, but if you already knew what was wrong reproducing the bug wouldn't be necessary.
4- Report the problem and the testcase to codadev or codalist and
possibly your reasoning why it is going wrong, at this point probably 90% of the real hard work is done.
5- Based on the feedback from codadev/codalist, you can try to write a
patch that fixes the problem. If the solution was trivial you probably already knew exactly what to change and you can just include the fix it along with the problem report. In some cases the problem might really be somewhere else, and you are chasing down just a symptom in which case the feedback from others would be useful.
Alternatively, you could just have a crazy/wonderful idea. Implement it, get other people excited and it might just end up in the main tree :)
Jan Received on 2002-10-18 16:45:30