On 12/31/2015 08:53 AM, Paul Menzel wrote:
change set #12804  proposes the following addition
to the file
Unfortunately, I do not fully understand the reasoning yet.
The core idea is to have a record of what happened where, and
Commercial members oftentimes have different standards and guidelines
. 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
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.