Dear coreboot folks,
change set #12804 [1] proposes the following addition to the file `Documentation/gerrit_guidelines.md`.
239 +* When bringing in a patch from another git repo, update the original 240 +git/gerrit tags by prepending the lines with 'Original-'. Marking 241 +the original text this way makes it much easier to tell what changes 242 +happened in which repository. This applies to these lines, not the actual 243 +commit message itself: 244 + Commit-Id: 245 + Change-Id: 246 + Signed-off-by: 247 + Reviewed-on: 248 + Tested-by: 249 + Reviewed-by: 250 +The script 'util/gitconfig/rebase.sh' can be used to help automate this. 251 +Other tags such as 'Commit-Queue' can simply be removed.
Unfortunately, I do not fully understand the reasoning yet. Why is it important, to (easily) know what tags were added in what repository.
*Commit-Id* is good to know, to easily find the commit in the other repository, but the *Change-Id* can be used for that too.
Signed-off-by is also not changed in the Linux kernel when it is pulled in. The new Signed-off-by line is just appended after the tags so it’s clear what way the commit or change set took.
The same is true for the other tags.
So I would actually propose, to leave the tags unchanged when moving them over.
What am I missing?
Thanks,
Paul
[1] https://review.coreboot.org/12804 [2] https://review.coreboot.org/#/c/12804/2/Documentation/gerrit_guidelines.md
On 12/31/2015 08:53 AM, Paul Menzel wrote:
change set #12804 [1] 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.
Alex
-
Alex G. -
Paul Menzel