[coreboot] Squash or not squash current Haswell patches?

[Paul Menzel]

Dear Stefan,


thank you for your response and your work on upstreaming the patches.


Am Dienstag, den 12.03.2013, 17:03 -0700 schrieb Stefan Reinauer:

> On Tue, Mar 12, 2013 at 3:01 PM, Paul Menzel wrote:
> 
> > first thanks to Google and Aaron for the Haswell patches. As most of
> > them seem to be fix-up patches I would say to squash those into the
> > Haswell commit and add comments into the code were appropriate.
> >
> > That would reduce the amount of patches and the one Haswell commit would
> > work right away(?).
> >
> > Or what do I miss?
>
> In the past a lot of the times new components have been published in one
> big chunk without development history. Doing so is the easiest way for the
> contributor, but it does not offer a very high degree of transparency about
> how the code was developed, and why it looks the way it looks. It also
> creates very large patches, which some in the coreboot community have
> disliked in the past. The code is not finished yet. Expect more patches
> even after the current merge is done.
> 
> Taking the feedback from previous contributions into regard, we decided to
> send out more fine grained contributions, and send them out as early as we
> possibly can, while making the review process easy on the community by not
> removing our thought process from the contribution.
> 
> I realize that large contributions and development at an incredibly high
> pace are a significant effort for the community to handle, and so I would
> like to make sure that we contribute, and continue contributing, in the
> best possible way. No matter how we form out the process, there will always
> be room for improvement, and there will always be time pressure on getting
> those contributions integrated.

The thing is that all patches are now published at once. So it is an
option to refactor them.

My original message mainly meant commits correcting PCI IDs for example.
These should be squashed. Having that history is not useful in my
opinion. Only if the commit message says exactly how much further the
start-up/boot process goes.

The main goal in my opinion and as I understood the suggestions in the
past is, that people can understand the changes best, which is not
necessarily identical to the actual bring-up process.

> Seeing both sides of the medal, being a corporate contributor as well as a
> maintainer of the coreboot community project, I am very happy about
> feedback on how to make life better and easier for everyone in the
> community while maintaining a high quality code base.

Thank you for addressing feedback. It is much appreciated!


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20130313/b6060b77/attachment.sig>