On 12/31/2015 08:53 AM, Paul Menzel wrote:
change set #12804  proposes the following addition to the file `Documentation/gerrit_guidelines.md`.
Unfortunately, I do not fully understand the reasoning yet.
The core idea is to have a record of what happened where, and accountability.
Commercial members oftentimes have different standards and guidelines than coreboot.org. I was able to convince my team to write patches as if they were to be submitted to coreboot.org, even though the customer would have accepted working patches with much less attention to detail. What I've noticed was that people were familiar with the customer's tools, guidelines, and repositories, but had no idea of the coreboot.org guidelines.
Another thing I've noticed, and this is key, is that products have to ship, and when the deadlines draw near, the attention to detail fades in exchange of getting things out the door. There are cases when people are about to finish a project, and are about to advance to the next project, but they have to complete that one last thing. There's the pressure from the old project to finish, and there's the pressure from the new project to start work.
That's the reason external patches must go through review, just like any other patch. The catch here is that oftentimes, it's members of the same team that approve patches in both places, so naturally, things get missed.
This means that, as time goes on, we need to be able to look at what went wrong, and update the guidelines and rules accordingly. You don't need the Original- as an absolute must, but it sure makes things a lot easier. It also makes sense in terms of keeping a logical separation of those tags. If people didn't consider it important, they wouldn't have written a script to automate it.