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
_______________________________________________
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
