Squash or not squash current Haswell patches?

[Paul Menzel]

Dear coreboot folks,

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?

Thanks,

Paul

[1] http://review.coreboot.org/

[Aaron Durbin]

On Tue, Mar 12, 2013 at 5:01 PM, Paul Menzel
 wrote:
> Dear coreboot folks,
>
> 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?

I'll let Stefan comment on the state of the patches. The last I heard
(a couple of days ago) was that there were still more to be sent (I
haven't been closely following Stefan's great upstreaming work).  The
Haswell development has had some churn mainly from experimenting with
some implementations of certain things. There's also probably more
patches that look like fix-up patches coming. So that doesn't really
answer your question. Sorry. It sounds like you'd rather see a big
Haswell patch that is our current development?

Sorry for the churn.

-Aaron

[Stefan Reinauer]

Hi, Paul,

On Tue, Mar 12, 2013 at 3:01 PM, Paul Menzel <
[e-mail]> 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.

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.