Additions:
- If you commit a kernel change that requires a userland configuration change of any type, then you also must make sure there is PHP code to control the userland change as needed (different sysctls, different means of configuring something, etc.).
Deletions:
Additions:
- You break the code, you fix it. Period. Even if your code breaks another subsystem. Your code caused the fallout. Yes this is not glamorous but it is the right thing to do (or back your code out until a proper fix can be obtained).
- Avoid changing the XML configuration structure whenever possible. Where that is infeasible, do not commit code that changes the XML configuration structure without adding configuration upgrade code at the same time.
- Avoid changing the XML configuration structure whenever possible. Where that is infeasible, do not commit code that changes the XML configuration structure without adding configuration upgrade code at the same time.
Deletions:
- Do not commit code that changes the configuration structure without adding configuration upgrade code at the same time.
Additions:
- If you commit a kernel change that requires a PHP configuration change, then you also must make sure there is PHP code to control the change as needed.
- Do not commit code that changes the configuration structure without adding configuration upgrade code at the same time.
- Do not commit code that changes the configuration structure without adding configuration upgrade code at the same time.
Deletions:
- Do not commit code unless you plan on adding upgrade code in a reasonable amount of time (1-2 weeks max) if it changes the config.xml layout in any way.
Additions:
- Do not commit code unless you plan on adding upgrade code in a reasonable amount of time (1-2 weeks max) if it changes the config.xml layout in any way.
Deletions:
Additions:
- If you commit a kernel change then you also need to make sure there is PHP code to control the change if need. Example: kernel patch introduces a on off switch for a subsystem.
Deletions:
Additions:
- You break the code, you fix it. Period. Even if your code breaks another subsystem. Your code caused the fallout. Yes this is not glamorous but it is the right thing to do (or back your code out until a proper fix can be obtained).
Deletions:
Additions:
- Do not commit code unless you plan on adding upgrade code in a reasonable amount of time (1-2 weeks max)
Deletions:
Additions:
- You break the code, you fix it. Period. Even if your code breaks another subsystem. Your code caused the fallout. Yes this is not glamorous but it is the right thing to do.
Deletions:
Additions:
- You break the code, you fix it. Period.
- If you commit a kernel change then you also need to make sure there is PHP code.
- Do not commit code unless you plan on adding upgrade in a reasonable amount of time (1-2 weeks max)
- If you commit a kernel change then you also need to make sure there is PHP code.
- Do not commit code unless you plan on adding upgrade in a reasonable amount of time (1-2 weeks max)
Deletions:
- If you commit a kernel change then you also need to make sure there is PHP code.
- Do not commit code unless you plan on adding upgrade in a reasonable amount of time (1-2 weeks max)
Additions:
- You break the code, you fix it. Period.
- If you commit a kernel change then you also need to make sure there is PHP code.
- Do not commit code unless you plan on adding upgrade in a reasonable amount of time (1-2 weeks max)
- If you commit a kernel change then you also need to make sure there is PHP code.
- Do not commit code unless you plan on adding upgrade in a reasonable amount of time (1-2 weeks max)
Additions:
- Never commit untested code.
- Never commit anything to any branch that knowingly causes a regression.
- Any major or high risk changes must first be done in a git clone and reviewed by another committer before merging into mainline.
- Pre-commit authorization such as in OpenBSD isn't used in pfSense except in the case of major changes. We do however run sanity checks on committed files and use access control to keep commits to authorized branches.
- special characters (e.g. umlauts) need to be coded as HTML entities. see: http://en.selfhtml.org/html/referenz/zeichen.htm (in German, sorry. but the table is self explanatory)
- Never commit anything to any branch that knowingly causes a regression.
- Any major or high risk changes must first be done in a git clone and reviewed by another committer before merging into mainline.
- Pre-commit authorization such as in OpenBSD isn't used in pfSense except in the case of major changes. We do however run sanity checks on committed files and use access control to keep commits to authorized branches.
- special characters (e.g. umlauts) need to be coded as HTML entities. see: http://en.selfhtml.org/html/referenz/zeichen.htm (in German, sorry. but the table is self explanatory)
Deletions:
- Massive changes to code that another developer makes significant changes to should be run past that dev as best practice
- Incorrectly reverting someone elses commit and causing them to hunt for a bug they know they fixed grants them the right to send the bar bill to you for a month :)
- Don't knowingly commit code that breaks the tree; sometimes you will have code that's work in progress than needs to be committed, try to commit it somewhere it won't break the tree (ie. interfaces_new.inc instead of interfaces.inc).
- Pre-commit authorization such as in OpenBSD isn't used in pfSense, we do however run sanity checks on committed files and use a cvs acl script to keep commits to authorized branches.
- special characters (e.g. umlauts) need to be coded as HTML entities. see: http://en.selfhtml.org/html/referenz/zeichen.htm (in German, sorry. but the table is self explaining)
Additions:
- the language=""JavaScript"" attribute for <script /> tags is deprecated. Use the type="text/javascript" attribute instead.
- always use lowercase attribute names for calling ""JavaScript"" events (e.g. onclick="foobar();")
- There shouldn't be a space between a function name and its argument list:
- always use lowercase attribute names for calling ""JavaScript"" events (e.g. onclick="foobar();")
- There shouldn't be a space between a function name and its argument list:
Deletions:
- always use lowercase attribute names for calling JavaScript events (e.g. onclick="foobar();")
- There shouldn't be a space between a function name and it's argument list:
Additions:
} else {
