Hello all,
I am currently working on helping the Chromium team get their coreboot patches upstreamed so I thought I should introduce myself to the community. My name is Isaac Christensen and I've been working for Sage Electronic Engineering since October. These will be my first pushes up to coreboot.org so if you have any comments on process or workflow feel free to let me know as I'm still learning.
Thank you, Isaac
On Tue, Jul 29, 2014 at 9:55 AM, Isaac isaac.christensen@se-eng.com wrote:
Hello all,
I am currently working on helping the Chromium team get their coreboot patches upstreamed so I thought I should introduce myself to the community. My name is Isaac Christensen and I've been working for Sage Electronic Engineering since October. These will be my first pushes up to coreboot.org so if you have any comments on process or workflow feel free to let me know as I'm still learning.
Great! We'll look forward to working with you on this.
It might be beneficial to drop by #coreboot on irc.freenode.net to answer questions / feedback about patches in real-time.
Dear Isaac,
Am Dienstag, den 29.07.2014, 10:55 -0600 schrieb Isaac:
I am currently working on helping the Chromium team get their coreboot patches upstreamed so I thought I should introduce myself to the community. My name is Isaac Christensen and I've been working for Sage Electronic Engineering since October.
welcome to coreboot and thank you very much for getting in contact with the coreboot community!
These will be my first pushes up to coreboot.org so if you have any comments on process or workflow feel free to let me know as I'm still learning.
As already commented on your change sets, I’d prefer if you could avoid squashing commits. Kyösti made very good points, so I won’t repeat them.
Also it’d be great to at least address such review comments and not ignore them and push the patches.
I am looking forward to the time when the future Chromium OS branches can be rebased on the coreboot upstream master branches. ;-)
Thanks,
Paul
* Paul Menzel paulepanter@users.sourceforge.net [140802 15:07]:
As already commented on your change sets, I’d prefer if you could avoid squashing commits. Kyösti made very good points, so I won’t repeat them.
One of the reasons Isaac has been squashing patches was that some in the community have been complaining about a vast amount of unsquashed patches last time, e.g.:
https://www.mail-archive.com/coreboot@coreboot.org/msg40272.html http://www.coreboot.org/pipermail/coreboot/2013-January/073543.html
As always, we have taken the community input under consideration, and tried acting upon it in the best possible way.
Are you suggesting that the needs have changed here?
Stefan
Am 05.08.2014 um 20:36 schrieb Stefan Reinauer:
Are you suggesting that the needs have changed here?
My only concern here would be to keep rebase/merge et al more functional, but it's probably already too late for that in the current state.
I suppose, once the trees are somewhat synchronized, one could build a merge commit between both histories to create a new baseline - and redo that every now and then.
Patrick
* Patrick Georgi patrick@georgi-clan.de [140805 21:32]:
Am 05.08.2014 um 20:36 schrieb Stefan Reinauer:
Are you suggesting that the needs have changed here?
My only concern here would be to keep rebase/merge et al more functional, but it's probably already too late for that in the current state.
Unfortunately, without significant amounts of testing, there is no guarantee that any given configuration in the Chromium HEAD or coreboot upstream HEAD will actually work on a given hardware. for every single build. If you want something that is tested for a given product, you will have to use a product firmware branch.
If you want to make changes to a given configuration, you will have to have equipment and knowledge in place to test and fix up your configuration yourself. That's certainly not something you'd get for free in any open source project, and particularly not in a hardware related project.
I suppose, once the trees are somewhat synchronized, one could build a merge commit between both histories to create a new baseline - and redo that every now and then.
The idea is indeed that the pain will go away if synchronization happens more regularly in both directions.
Stefan
Dear Stefan,
Am Dienstag, den 05.08.2014, 20:36 +0200 schrieb Stefan Reinauer:
- Paul Menzel [140802 15:07]:
As already commented on your change sets, I’d prefer if you could avoid squashing commits. Kyösti made very good points, so I won’t repeat them.
One of the reasons Isaac has been squashing patches was that some in the community have been complaining about a vast amount of unsquashed patches last time, e.g.:
https://www.mail-archive.com/coreboot@coreboot.org/msg40272.html
very interesting read. ;-)
First of, I am sorry, that it looks like one time I write this and the other time that. But it is more my fault for not being clear. So let me clarify. By fix-ups I meant typos or wrong PCI IDs. Looking at the squashed commits in [1], from my point of view, these are no fix-ups and should not have been squashed.
http://www.coreboot.org/pipermail/coreboot/2013-January/073543.html
Well, that message actually asks for more communication with the community, so is unrelated.
As always, we have taken the community input under consideration, and tried acting upon it in the best possible way.
Yes, thanks again for your answer.
Are you suggesting that the needs have changed here?
The basic need has not changed and it looks like it was a misunderstanding in the past.
Thanks,
Paul
Dear coreboot folks,
Am Dienstag, den 05.08.2014, 22:59 +0200 schrieb Paul Menzel:
Am Dienstag, den 05.08.2014, 20:36 +0200 schrieb Stefan Reinauer:
- Paul Menzel [140802 15:07]:
[…]
Are you suggesting that the needs have changed here?
The basic need has not changed and it looks like it was a misunderstanding in the past.
looking at how the commits are squashed, that means the commit message is *not* rewritten but just appended after each other [2][3], I still think it’d be better to upstream each commit separately as that way the author information is kept and it is actually more readable when using `git log` or `git log --format=oneline`.
Thanks,
Paul
[2] http://review.coreboot.org/6916/ [3] http://review.coreboot.org/6883