Successfully reported this slideshow.

How to get reviewers to block your changes

2

Share

Loading in …3
×
1 of 14
1 of 14

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

How to get reviewers to block your changes

  1. 1. How to Get Reviewers to Block your Changes Tips to decrease your productivity by 75%+!
  2. 2. Add spelling/grammatical errors to the commit message Remov some dupcilate unit tests Their our several locations wear some unit test mixins our incorrectly used multiple times...
  3. 3. Make the commit message unrelated to the change ● Describe a problem only vaguely related to the change. ● Use “Closes-Bug:” like hashtags on Twitter. (The numbers afterward should be randomized)
  4. 4. Fix a known bug without a link to its Launchpad bug ID ● Launchpad is used to track the status of bugs. Make sure the core team and release manager don’t know that a critical bug has been addressed.
  5. 5. Make a high-impact change without a blueprint Anything that changes the following: ● The REST API or messaging API ● Internal APIs used by many files ● Runtime behavior that affects users
  6. 6. No unit tests Don’t include any unit tests with your change. This is especially true if existing tests didn’t break with a behavior changing patch.
  7. 7. Describe the Bug Describe the bug in the commit messages instead of in the fix. There is a race condition in the L3 code. A deadlock exists. Not anymore. Closes-Bug: XXXXX
  8. 8. Include 1 test for a 1000-line change Make the number of tests you create inversely proportional to the number of lines changed.
  9. 9. Change whitespace Change as much unrelated whitespace as possible. This makes back-porting changes terrible for stable maintainers.
  10. 10. Fix unrelated bugs in the same patch Make small changes to nearby functions that are completely irrelevant to the change at hand. This confuses reviewers and also makes back-porting very painful.
  11. 11. Make broad changes that don’t do anything “Fix capitalization of every inline comment in the code base” This produces tons of merge conflicts for other patches in review.
  12. 12. Long response times Wait weeks to respond to comments from reviewers and to upload corrected patches so reviewers have to relearn the whole thing.
  13. 13. Make functions untestable Make functions that fulfill the following requirements: ● >100 lines ● variable names so short they are unreadable ● variable names so long they require several line-wraps to work with
  14. 14. Any more?

×