|
@@ -120,27 +120,28 @@ are skipped. From that perspective, it is useful to use
|
|
|
@section contributorGuideReview Going through a review
|
|
@section contributorGuideReview Going through a review
|
|
|
|
|
|
|
|
Once all those are checked and working, feel free to create a ticket
|
|
Once all those are checked and working, feel free to create a ticket
|
|
|
-for your patch (http://bind10.isc.org) or attach your patch to the
|
|
+for your patch at http://bind10.isc.org/ or attach your patch to an
|
|
|
-existing ticket if there is one. You may drop a note to bind10 or dhcp
|
|
+existing ticket if you have fixed it. It would be nice if you also join the \c bind10 or \c dhcp
|
|
|
chatroom saying that you have submitted a patch. Alternatively, you
|
|
chatroom saying that you have submitted a patch. Alternatively, you
|
|
|
-may send a note to bind10-dev or bind10-dhcp lists.
|
|
+may send a note to the \c bind10-dev or \c bind10-dhcp mailing lists.
|
|
|
|
|
|
|
|
Here's the tricky part. One of BIND10 developers will review your
|
|
Here's the tricky part. One of BIND10 developers will review your
|
|
|
patch, but it may not happen immediately. Unfortunately, developers
|
|
patch, but it may not happen immediately. Unfortunately, developers
|
|
|
-are usually working under tight schedule, so any extra unplanned
|
|
+are usually working under a tight schedule, so any extra unplanned
|
|
|
-review work sometimes make take a while. Having said that, we value
|
|
+review work may take a while sometimes. Having said that, we value
|
|
|
external contributions very much and will do whatever we can to
|
|
external contributions very much and will do whatever we can to
|
|
|
review patches in a timely manner. Don't get discouraged if your
|
|
review patches in a timely manner. Don't get discouraged if your
|
|
|
patch is not accepted after first review. To keep the code quality
|
|
patch is not accepted after first review. To keep the code quality
|
|
|
high, we use the same review processes for internal code and for
|
|
high, we use the same review processes for internal code and for
|
|
|
-external patches. It may take several cycles of review/updated patch
|
|
+external patches. It may take some cycles of review/updated patch
|
|
|
submissions before the code is finally accepted.
|
|
submissions before the code is finally accepted.
|
|
|
|
|
|
|
|
-Once the process is almost completed, the developer will likely ask
|
|
+Once the process is almost complete, the developer will likely ask
|
|
|
you how you would like to be credited. The typical answers are by
|
|
you how you would like to be credited. The typical answers are by
|
|
|
-first,last name, by nickname, by company or anonymously. Typically we
|
|
+first and last name, by nickname, by company name or anonymously. Typically we
|
|
|
-will add a note to ChangeLog. If the contributted feature is big or
|
|
+will add a note to the \c ChangeLog and also set you as the author of the
|
|
|
-critical for whatever reason, it may be also mentioned in release
|
|
+commit applying the patch. If the contributted feature is big or
|
|
|
|
|
+critical for whatever reason, it may also be mentioned in release
|
|
|
notes.
|
|
notes.
|
|
|
|
|
|
|
|
@section contributorGuideExtra Extra steps
|
|
@section contributorGuideExtra Extra steps
|
Mukund Sivaraman