Lines Matching refs:to

4 This document describes what you need to do to contribute to Busybox, where
5 you can help, guidelines on testing, and how to submit a well-formed patch
6 that is more likely to be accepted.
15 So you want to contribute to Busybox, eh? Great, wonderful, glad you want to
17 you need to do:
23 This is a necessary first step. Please do not try to work with the last
28 For information on how to check out Busybox development tree, please look at the
37 No one is required to read the entire archives of the mailing list, but you
40 you're the first to discover a problem, post a message and let the rest of us
47 If you have a serious interest in Busybox, i.e., you are using it day-to-day or
48 as part of an embedded project, it would be a good idea to join the mailing
64 Before plunging ahead, it's a good idea to send a message to the mailing list
65 that says: "Hey, I was thinking about adding the 'transmogrify' feature to the
67 want to CC the maintainer (if any) with your question.
74 Busybox can always use improvement! If you're looking for ways to help, there
81 Before listing the areas where you _can_ help, it's worthwhile to mention the
82 areas where you shouldn't bother. While Busybox strives to be the "Swiss Army
86    we do not want to start adding mkfs/fsck tools for every (or any)
92    and up-to-date).
95    that was designed for your device; don't try to shoehorn them into Busybox.
105 If you find bugs, please submit a detailed bug report to the busybox mailing
108 anyone else to duplicate the bug on their own machine. The following is such
146 Work is being done to automatically generate documentation from sources,
147 especially from the usage.h file. If you want to correct the documentation,
148 please make changes to the pre-generation parts, rather than the generated
149 documentation. [More to come on this later...]
151 It is preferred that modifications to documentation be submitted in patch
152 format (more on this below), but we're a little more lenient when it comes to
166 any spot, these are all invitations for you to contribute.
172 If you want to add a new applet to Busybox, we'd love to see it. However,
175 guys accept applet 'foo' into Busybox if I were to write it?" If the answer is
195    is very Perl-specific, but the advice given in here applies equally well to
207  - Add testcases to tests/testcases.
226 Here are some guidelines on how to submit a patch to Busybox.
237 You can send the resulting .patch file to the mailing list with a description
242 Also, feel free to help test other people's patches and reply to them with
249 post your findings to the mailing list.
252 Please do not try to "bundle" two patches together into one. Make single,
253 discreet changes on a per-patch basis. Sometimes you need to make a patch that
261 It's considered good form to test your new feature before you submit a patch
262 to the mailing list, and especially before you push a change to Git. Here
263 are some guidelines on how to test your changes.
284 If you don't want your patch to be lost or forgotten, send it to the busybox
287 	[PATCH] - Adds "transmogrify" feature to "foo"
297 	This patch adds the "transmogrify" feature to the "foo" applet. I have
307 Even after you send a brilliant patch to the mailing list, sometimes it can go
308 unnoticed, un-replied-to, and sometimes (sigh) even lost. This is an
309 unfortunate fact of life, but there are steps you can take to help your patch
316 A patch that includes small, isolated, obvious changes is more likely to be
326 Specifically, patches are more likely to be accepted if they are provably more
338 It's considered good form to abide by the established coding style used in a
339 project; Busybox is no exception. We have gone so far as to delineate the
354 responses from queries to applet maintainer or positive responses from folks
357 We've made strident efforts to put a useful "collaboration" infrastructure in
362 Send Patches to the Bug Tracking System
366 section, but it is worth mentioning again. A patch sent to the mailing list
367 might be unnoticed and forgotten. A patch sent to the bug tracking system will
368 be stored and closely connected to the bug it fixes.
375 applies when submitting patches to the mailing list for approval. The way you
377 (if not more so). Being rude to the maintainers is not an effective way to
383 Pushing Changes to Git
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.
392 should test your changes before you push them. You should also talk to an
393 applet maintainer before you make any kind of sweeping changes to somebody
394 else's code. Big changes should still go to the mailing list first. Remember,
405 Generally, you should feel free to push a change if:
412 The more of the above are true, the better it is to just push a change
413 directly to Git.
419 Even if you have push access, you should probably still post a patch to the
427 The more of the above are true, the better it is to post a patch to the
438 good-natured bunch and will work with you to help get your patches into shape