Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
How to Get Reviewers 
to Block your 
Changes 
Tips to decrease your productivity by 75%+!
Add spelling/grammatical errors to the commit 
message 
Remov some dupcilate unit tests 
Their our several locations wear ...
Make the commit message unrelated to the change 
● Describe a problem only vaguely related to 
the change. 
● Use “Closes-...
Fix a known bug without a link to its Launchpad bug ID 
● Launchpad is used to track the status of 
bugs. Make sure the co...
Make a high-impact change without a blueprint 
Anything that changes the following: 
● The REST API or messaging API 
● In...
No unit tests 
Don’t include any unit tests with your change. 
This is especially true if existing tests didn’t 
break wit...
Describe the Bug 
Describe the bug in the commit messages 
instead of in the fix. 
There is a race condition in the L3 cod...
Include 1 test for a 1000-line change 
Make the number of tests you create inversely 
proportional to the number of lines ...
Change whitespace 
Change as much unrelated whitespace as 
possible. 
This makes back-porting changes terrible for 
stable...
Fix unrelated bugs in the same patch 
Make small changes to nearby functions that 
are completely irrelevant to the change...
Make broad changes that don’t do anything 
“Fix capitalization of every inline comment in 
the code base” 
This produces t...
Long response times 
Wait weeks to respond to comments from 
reviewers and to upload corrected patches so 
reviewers have ...
Make functions untestable 
Make functions that fulfill the following 
requirements: 
● >100 lines 
● variable names so sho...
Any more?
Upcoming SlideShare
Loading in …5
×

How to get reviewers to block your changes

625 views

Published on

Tips to get OpenStack reviewers to block your changes

Published in: Technology
  • Be the first to comment

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?

×