Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
How to get reviewers to block your changes
1. How to Get Reviewers
to Block your
Changes
Tips to decrease your productivity by 75%+!
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. 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. 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. 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. 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. 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. Include 1 test for a 1000-line change
Make the number of tests you create inversely
proportional to the number of lines changed.
9. Change whitespace
Change as much unrelated whitespace as
possible.
This makes back-porting changes terrible for
stable maintainers.
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. 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. 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. 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
