Re: [coreboot] New patch to review for coreboot: 0ae65d8 Add support for "Butterfly" Chromebook

[Peter Stuge]

ron minnich wrote:
> This is another case where I would kind of prefer to let the "shipping
> version " if the code go in as is, then put the revs in.

I understand that, but it would nevertheless be nice to pretend to
care about review feedback. I don't think anyone expects feedback to
neccessarily lead to further patchsets on a change, especially for
code that is already shipping.

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.
> it's useful to have a version in the repo that is exactly what's on
> that machine

Agreed.
> I think it would be wonderful if we could get your comments in and do
> another rev based on that

At the very least maybe keep things in mind for the future.
> with the caveat that at that point you're no longer building what's
> on the machine and there are no guarantees.

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.

//Peter

New patch to review for coreboot: 0ae65d8 Add support for "Butterfly" Chromebook

[ron minnich]

On Mon, Feb 11, 2013 at 3:49 PM, Peter Stuge  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