Changeset 2725 in MondoRescue for branches/2.2.9/mindi-busybox/docs/contributing.txt
- Timestamp:
- Feb 25, 2011, 9:26:54 PM (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
branches/2.2.9/mindi-busybox/docs/contributing.txt
r821 r2725 18 18 19 19 20 Checkout the Latest Code from CVS21 ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~20 Checkout the Latest Code 21 ~~~~~~~~~~~~~~~~~~~~~~~~ 22 22 23 23 This is a necessary first step. Please do not try to work with the last … … 26 26 Don't make your work obsolete before you start! 27 27 28 For information on how to check out Busybox from CVS, please look at the28 For information on how to check out Busybox development tree, please look at the 29 29 following links: 30 30 31 http://busybox.net/cvs_anon.html 32 http://busybox.net/cvs_howto.html 31 http://busybox.net/source.html 33 32 34 33 … … 88 87 filesystem under the sun. (fsck_minix.c and mkfs_minix.c are living on 89 88 borrowed time.) There are far too many of these tools out there. Use 90 the upstream version. Not everything has to be part of Busybox. 91 92 - Any partitioning tools: Partitioning a device is typically done once and 93 only once, and tools which do this generally do not need to reside on the 94 target device (esp a flash device). If you need a partitioning tool, grab 95 one (such as fdisk, sfdisk, or cfdisk from util-linux) and use that, but 96 don't try to merge it into busybox. These are nasty and complex and we 97 don't want to maintain them. 89 the upstream version. Rationale: bugs in these tools can destroy 90 vast amounts of data. Keeping up with filesystem format development 91 is impractical (especially in the area of keeping fsck tool safe 92 and up-to-date). 98 93 99 94 - Any disk, device, or media-specific tools: Use the -utils or -tools package … … 103 98 independent. Do not send us tools that cannot be used across multiple 104 99 platforms / arches. 105 106 - Any daemons that are not essential to basic system operation. To date, only107 syslogd and klogd meet this requirement. We do not need a web server, an108 ftp daemon, a dhcp server, a mail transport agent or a dns resolver. If you109 need one of those, you are welcome to ask the folks on the mailing list for110 recommendations, but please don't bloat up Busybox with any of these.111 100 112 101 … … 136 125 137 126 $ date 138 llegal instruction127 Illegal instruction 139 128 140 129 I am using Debian unstable, kernel version 2.4.19-rmk1 on an Netwinder, 141 and the latest uClibc from CVS. Thanks for the wonderful program!130 and the latest uClibc from CVS. 142 131 143 132 -Diligent … … 200 189 These are dirty jobs, but somebody's gotta do 'em. 201 190 202 - Converting applets to use getopt() for option processing. Type 'find -name203 '*.c'|grep -L getopt' to get a listing of the applets that currently don't204 use getopt. If a .c file processes no options, it should have a line that205 reads: /* no options, no getopt */ somewhere in the file.206 207 - Replace any "naked" calls to malloc, calloc, realloc, str[n]dup, fopen with208 the x* equivalents found in libbb/xfuncs.c.209 210 191 - Security audits: 211 192 http://www.securityfocus.com/popups/forums/secprog/intro.shtml … … 236 217 Other useful links: 237 218 238 - the comp.lang.c FAQ: http:// web.onetelnet.ch/~twolf/tw/c/index.html#Sources219 - the comp.lang.c FAQ: http://home.datacomm.ch/t_wolf/tw/c/index.html#Sources 239 220 240 221 … … 249 230 ~~~~~~~~~~~~~~ 250 231 251 If you've got anonymous CVS access set up, making a patch is simple. Just make 252 sure you're in the busybox/ directory and type 'cvs diff -bwu > mychanges.patch'. 232 If you've got anonymous Git access set up, making a patch is simple. Just make 233 sure you're in the busybox/ directory and type: 234 235 git diff -b -w > mychanges.patch 236 253 237 You can send the resulting .patch file to the mailing list with a description 254 238 of what it does. (But not before you test it! See the next section for some … … 258 242 Also, feel free to help test other people's patches and reply to them with 259 243 comments. You can apply a patch by saving it into your busybox/ directory and 260 typing 'patch < mychanges.patch'. Then you can recompile, see if it runs, test 261 if it works as advertised, and post your findings to the mailing list. 244 typing: 245 246 patch -p1 < mychanges.patch 247 248 Then you can recompile, see if it runs, test if it works as advertised, and 249 post your findings to the mailing list. 262 250 263 251 NOTE: Please do not include extraneous or irrelevant changes in your patches. … … 272 260 273 261 It's considered good form to test your new feature before you submit a patch 274 to the mailing list, and especially before you commit a change to CVS. Here262 to the mailing list, and especially before you push a change to Git. Here 275 263 are some guidelines on how to test your changes. 276 264 … … 368 356 369 357 We've made strident efforts to put a useful "collaboration" infrastructure in 370 place in the form of mailing lists, the bug tracking system, and CVS. Please358 place in the form of mailing lists, the bug tracking system, and Git. Please 371 359 use these resources. 372 360 … … 393 381 394 382 395 Committing Changes to CVS 396 ---------------------- ---383 Pushing Changes to Git 384 ---------------------- 397 385 398 386 If you submit several patches that demonstrate that you are a skilled and wise 399 coder, you may be invited to become a committer, thus enabling you to commit400 changes directly to CVS. This is nice because you don't have to wait for401 someone else to commityour change for you, you can just do it yourself.387 coder, you may be invited to become a committer, thus enabling you to push 388 changes directly to Git. This is nice because you don't have to wait for 389 someone else to push your change for you, you can just do it yourself. 402 390 403 391 But note that this is a privilege that comes with some responsibilities. You 404 should test your changes before you committhem. You should also talk to an392 should test your changes before you push them. You should also talk to an 405 393 applet maintainer before you make any kind of sweeping changes to somebody 406 394 else's code. Big changes should still go to the mailing list first. Remember, 407 395 being wise, polite, and discreet is more important than being clever. 408 396 409 410 When To Commit 411 ~~~~~~~~~~~~~~ 412 413 Generally, you should feel free to commit a change if: 397 For more information on Git push access, see: 398 399 http://busybox.net/developer.html 400 401 402 When To Push 403 ~~~~~~~~~~~~ 404 405 Generally, you should feel free to push a change if: 414 406 415 407 - Your changes are small and don't touch many files … … 418 410 - It's obviously the Right Thing 419 411 420 The more of the above are true, the better it is to just commita change421 directly to CVS.422 423 424 When Not To Commit425 ~~~~~~~~~~~~~~~~ ~~426 427 Even if you have commit rights, you should probably still post a patch to the412 The more of the above are true, the better it is to just push a change 413 directly to Git. 414 415 416 When Not To Push 417 ~~~~~~~~~~~~~~~~ 418 419 Even if you have push access, you should probably still post a patch to the 428 420 mailing list if: 429 421 … … 434 426 435 427 The more of the above are true, the better it is to post a patch to the 436 mailing list instead of committing.428 mailing list instead of pushing. 437 429 438 430 … … 446 438 good-natured bunch and will work with you to help get your patches into shape 447 439 or help you make contributions. 448 449
Note:
See TracChangeset
for help on using the changeset viewer.