Time for another story from a certain Korean corporation.

A certain abomination of an OS with a capital T in its name, keeps all its sources in git. The integration is so tight, that components are built by developers using a tool named Git Build System. For a long time development was based on git repos with gerrit in between for code review. But something sinister lurked in the shadows and one day decided to strike.

In all their wisdom, management decided that developing a Linux-based OS should be done on Windows; all builds shouldn’t be done locally but sent to some build server and the results downloaded, and that became the Standard. Teams in Korea began working with Visual Studio, while other teams in the rest of the world managed to keep their old ways and actually stay productive.

At some point, management decided that all issue tracking software in the world is not enough and decided to devote a metric ton of money and countless manhours to build something, which managed to reshape the definition of “broken beyond uselessness”. A form so chaotic, it’s beautiful in a perverse way. A single issue is made of countless tabs of forms, each spanning more than a FullHD monitor can show. All written in 1/3 English, 1/3 Korean and 1/3 unknown hybrid language, with features like -13 456 bug count and issue state diagrams taking three Excel sheets to describe (bonus WTF: drawing state diagrams in Excel). Thus the Standard was amended.

What does all that have to do with git and developer environment? In time Windows guys with Korean management (which has the final say in everything without discussion) discovered that git on Windows is somehow even worse than git in general, and their workflow generally sucks. They also discovered an ancient proprietary VCS called Perforce which worked on Windows and could be integrated with the issue tracker. Therefore the only logical conclusion was to start using Perforce. They only forgot to tell everyone else to stop using git…

Time went by and Bad Things started to appear. Git/gerrit was official in some teams, but Perforce was official in other teams (even working on the same component). Some patches went there, some there. The management finally decided Perforce code should be used as THE source for building OS images. Again, they only forgot to tell everyone else to stop using git…

Both repositories diverged to the point of being almost incompatible. Issues in Perforce code were given to git teams, which resulted in a litany of WTFs. After all, there’s not many things more fun than being tasked with fixing a bug in code that you physically don’t have. ASAP. Meetings took place, arrangements were made to rectify the situation. Months later, the situation is still the same.

One implication was code review process. With gerrit in place, that was a non-issue. But the Korean teams didn’t (and still don’t) understand the notion of code review and pushed everything directly to the repo. The quality of some patches was so bad that enforcing code review became top priority for non-Korean teams. Finally, a solution was developed – MS Word based code review. Each changeset needs to be attached to a bug in the tracker. Each bug can have a Word document attached with a request for code review. That document is a three pages long form with information so useless, nobody even wants to read it. At the end there’s a place for copy-pasting a diff for each file changed, with the explanation why. Reviewers are supposed to fill a Word form with details about which line they comment on and what their issue with it is.

Submitting a patch, clicking through the awful issue tracker and filling the form takes literal hours. All this because using git with gerrit was too tough. Fortunately, the review form has fields listing times taken by various steps in fixing a bug. Maybe someday someone will read how long pushing the code actually takes.

No, they won’t.