On Mon, Feb 11, 2013 at 3:49 PM, Peter Stuge peter@stuge.se wrote:
I understand that, but it would nevertheless be nice to pretend to care about review feedback.
I think we care a lot about feedback. But if we get this committed, then people can build exactly what's on the shipping hardware. I think that's really important!
I would like to have the changes from the community highly visible as two different commits in the repo, instead of two variations on CLs ... I just think it makes it harder for people to see how it changed. I really want this to be very visible.
So from my POV, this is making the community input and feedback MORE, rather than LESS, visible.
I don't think anyone expects feedback to neccessarily lead to further patchsets on a change, especially for code that is already shipping.
I would hope we'd see some changes ...
On the odd chance that there is something valuable that the community can contribute, leaving next to no room for feedback can easily make people feel discouraged.
But they should not, esp. if the goal is to make their ideas highly visible, and that's what this is all about. So, folks, don't be shy, let's see those improvements ...
Of course. I'd suggest to additionally create a git tag on the commit, with a name that somehow corresponds to supply chain identification of the machine.
But are we not in agreement then? - hardware ships with coreboot - we push a CL to the repo, and get a commit that is EXACTLY what is on the hardware, so people can recreate it - community suggests improvements, and we do a second commit, which brings in the community's wisdom. Then, we have these two commits and it's easy for people to see what changed. Also, they can do a build of what the machine shipped with, and a build of the improvements, and look for differences. To me, this is a pretty good situation.
For the long term, I'd still much rather git diff etc. etc. than have to hop to a web page and look at two different versions of a CL. Maybe that's just me?
ron