developing mc

BARTHAZI Andras andras at barthazi.hu
Sun Dec 1 09:27:38 UTC 2002


Hi!

> Another problem - most code was written long ago and not by 
> me.  I'm trying to enforce rules that were not in effect when 
> the bulk of code was written.  This means that I often have 
> to clean up existing code, so that it doesn't serve as a bad 
> example for the new developers.  That takes time too.

Just a recommendation: it would be better, if you could write these
rules down (the way of patching, the rules of coding, recommended way,
depreceated parts of the program, the working of the program [just a
rude way], etc.). I know it's a good job again and you have other more
important task, just I think it could help for the totally newbies like
me, who would like to help a bit.

It could work that you just comment a code at deprecated places ('ASK ME
IF YOU WOULD LIKE TO MODIFY IT') or something like this.

Or the way of patching:

0. one letter - one patch
0. never send pure code to the mailing list, just diffs
0. when you send a patch, tell which version of the
    code you have patched.
0. be patient, the main coders do it in their free time,
    maybe their just answer your mail after a few
    days

1. look around the code, the style of code
2. first recommend the patch on the mc-devel mailing list
3. discuss the other developers about the way of realize it
4. do it clear, and try to write a code that "nice"
5. send your patch in universal diff format (use diff -u for it),
    one patch in one mail, and try to detail what the code
    do

If I read these documentations before I patch, then I would write less
'stupid newbie' mails. :)

Comments? ;)

Bye,
  Andras





More information about the mc-devel mailing list