- Style guide compliance. See: docs/style-guide.txt - Add testcases to tests/testcases. - Makefile improvements:   http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html   (I think the recursive problems are pretty much taken care of at this point, non?) - "Ten Commandments" compliance: (this is a "maybe", certainly not as   important as any of the previous items.)    http://web.onetelnet.ch/~twolf/tw/c/ten_commandments.htmlOther useful links: - the comp.lang.c FAQ: http://web.onetelnet.ch/~twolf/tw/c/index.html#SourcesSubmitting Patches To Busybox-----------------------------Here are some guidelines on how to submit a patch to Busybox.Making A Patch~~~~~~~~~~~~~~If you've got anonymous CVS access set up, making a patch is simple. Just makesure you're in the busybox/ directory and type 'cvs diff -bwu > mychanges.patch'.You can send the resulting .patch file to the mailing list with a descriptionof what it does. (But not before you test it! See the next section for someguidelines.) It is preferred that patches be sent as attachments, but it isnot required.Also, feel free to help test other people's patches and reply to them withcomments. You can apply a patch by saving it into your busybox/ directory andtyping 'patch < mychanges.patch'. Then you can recompile, see if it runs, testif it works as advertised, and post your findings to the mailing list.NOTE: Please do not include extraneous or irrelevant changes in your patches.Please do not try to "bundle" two patches together into one. Make single,discreet changes on a per-patch basis. Sometimes you need to make a patch thattouches code in many places, but these kind of patches are rare and should becoordinated with a maintainer.Testing Guidelines~~~~~~~~~~~~~~~~~~It's considered good form to test your new feature before you submit a patchto the mailing list, and especially before you commit a change to CVS. Hereare some guidelines on how to test your changes. - Always test Busybox applets against GNU counterparts and make sure the   behavior / output is identical between the two. - Try several different permutations and combinations of the features you're   adding (i.e., different combinations of command-line switches) and make sure   they all work; make sure one feature does not interfere with another. - Make sure you test compiling against the source both with the feature   turned on and turned off in Config.h and make sure Busybox compiles cleanly   both ways. - Run the multibuild.pl script in the tests directory and make sure   everything checks out OK. (Do this from within the busybox/ directory by   typing: 'tests/multibuild.pl'.)Making Sure Your Patch Doesn't Get Lost~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~If you don't want your patch to be lost or forgotten, send it to the bugtracking system (http://bugs.lineo.com). You do this by emailing your patch ina message to submit@bugs.lineo.com with a subject line something like this:	[PATCH] - Adds "transmogrify" feature to "foo"In the body, you should have a pseudo-header that looks like the following:    Package: busybox    Version: v0.50pre (or whatever the current version is)    Severity: wishlistThe remainder of the body should read along these lines:	This patch adds the "transmogrify" feature to the "foo" applet. I have	tested this on [arch] system(s) and it works. I have tested it against the	GNU counterparts and the outputs are identical. I have run the scripts in	the 'tests' directory and nothing breaks.Detailed instructions on how to submit a bug to the tracking system are at:	http://bugs.lineo.com/Reporting.htmlIf you have a patch that will fix and close a reported bug, please send amessage to [bugnumber]@bugs.lineo.com with your patch attached. It will catchpeople's attention if you have a subject line like the following:	[PATCH INCLUDED] - Fix attached, please apply and close this bugImproving Your Chances of Patch Acceptance------------------------------------------Even after you send a brilliant patch to the mailing list, sometimes it can gounnoticed, un-replied-to, and sometimes (sigh) even lost. This is anunfortunate fact of life, but there are steps you can take to help your patchget noticed and convince a maintainer that it should be added:Be Succinct~~~~~~~~~~~A patch that includes small, isolated, obvious changes is more likely to beaccepted than a patch that touches code in lots of different places or makessweeping, dubious changes.Back It Up~~~~~~~~~~Hard facts on why your patch is better than the existing code will go a longway toward convincing maintainers that your patch should be included.Specifically, patches are more likely to be accepted if they are provably morecorrect, smaller, faster, simpler, or more maintainable than the existingcode.Conversely, any patch that is supported with nothing more than "I think thiswould be cool" or "this patch is good because I say it is and I've got a Phdin Computer Science" will likely be ignored.Follow The Style Guide~~~~~~~~~~~~~~~~~~~~~~It's considered good form to abide by the established coding style used in aproject; Busybox is no exception. We have gone so far as to delineate the"elements of Busybox style" in the file docs/style-guide.txt. Please followthem.Work With Someone Else~~~~~~~~~~~~~~~~~~~~~~Working on a patch in isolation is less effective than working with someoneelse for a variety of reasons. If another Busybox user is interested in whatyou're doing, then it's two (or more) voices instead of one that can petitionfor inclusion of the patch. You'll also have more people that can test yourchanges, or even offer suggestions on better approaches you could take.Getting other folks interested follows as a natural course if you've receivedresponses from queries to applet maintainer or positive responses from folkson the mailing list.We've made strident efforts to put a useful "collaboration" infrastructure inplace in the form of mailing lists, the bug tracking system, and CVS. Pleaseuse these resources.Send Patches to the Bug Tracking System~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~This was mentioned above in the "Making Sure Your Patch Doesn't Get Lost"section, but it is worth mentioning again. A patch sent to the mailing listmight be unnoticed and forgotten. A patch sent to the bug tracking system willbe stored and closely connected to the bug it fixes.Be Polite~~~~~~~~~The old saying "You'll catch more flies with honey than you will with vinegar"applies when submitting patches to the mailing list for approval. The way youpresent your patch is sometimes just as important as the actual patch itself(if not more so). Being rude to the maintainers is not an effective way toconvince them that your patch should be included; it will likely have theopposite effect.Committing Changes to CVS-------------------------If you submit several patches that demonstrate that you are a skilled and wisecoder, you may be invited to become a committer, thus enabling you to commitchanges directly to CVS. This is nice because you don't have to wait forsomeone else to commit your change for you, you can just do it yourself.But note that this is a priviledge that comes with some responsibilities. Youshould test your changes before you commit them. You should also talk to anapplet maintainer before you make any kind of sweeping changes to somebodyelse's code. Big changes should still go to the mailing list first. Remember,being wise, polite, and discreet is more important than being clever.When To Commit~~~~~~~~~~~~~~Generally, you should feel free to commit a change if: - Your changes are small and don't touch many files - You are fixing a bug - Somebody has told you that it's okay - It's obviously the Right ThingThe more of the above are true, the better it is to just commit a changedirectly to CVS.When Not To Commit~~~~~~~~~~~~~~~~~~Even if you have commit rights, you should probably still post a patch to themailing list if: - Your changes are broad and touch many different files - You are adding a feature - Your changes are speculative or experimental (i.e., trying a new algorithm) - You are not the maintainer and your changes make the maintainer cringeThe more of the above are true, the better it is to post a patch to themailing list instead of committing.Final Words-----------If all of this seems complicated, don't panic, it's really not that tough. Ifyou're having difficulty following some of the steps outlined in thisdocument don't worry, the folks on the Busybox mailing list are a fairlygood-natured bunch and will work with you to help get your patches into shapeor help you make contributions.