On Wed, Oct 18, 2017 at 10:31 AM, Nico Huber <nico.h@gmx.de> wrote:

On 17.10.2017 01:14, David Hendricks wrote:

On Sat, Oct 14, 2017 at 7:20 AM, Stefan Tauner <stefan.tauner@gmx.at> wrote:

While there was a bunch of patches that have been piled up back then it
was less of a problem then the increasing divergence between the
chromiumos fork and upstream. Thus we have discussed ways to converge
that (by pulling changes mainly from upstream into chromium but also
vice versa) and also increase the pace of merging stuff into upstream
later. This was still with no intention to switch to git because of
Carl-Daniel's concerns.

I'm surprised that you think that chromiumos's divergence is a *worse*
problem than the huge backlog of upstream patches. The chromiumos fork is
self-contained, has its own review system, its own testing, and is targeted
at a narrow set of devices. I don't understand how it could have been a
problem for upstream and would be interested if you can elaborate on this
point.

I think there are at least two views on this:

What might happen in such a case: People loose interest in upstream and
less patches get send there. (This might even have a positive effect on
the patch queue.)

What I think happened (and maybe Stefan had something like this in
mind): Progress on upstream stalled on more invasive topics because
people tried to find a solution fitting both branches, first. FWIW,
this was the case for better layout support in upstream. Maybe there
were more topics stalled, I don't know the cros fork well enough.

That makes sense. However I think it's worth considering _why_ people lose interest rather than blaming forks. IMO much of this is due to the historically glacial pace of reviews, commits, and releases, which might be fine for hobbyists or occasional users but was simply unworkable for commercial development.

The good news is that this is getting fixed now that we have modern code management and review systems in-place. Contributors have more ways to submitting patches (mailing list, PR on Github, or push to review.coreboot.org). Tracking and rebasing patches and revisions is much, much easier now with Gerrit. Jenkins provides some value for sanity checking, and Stefan's upcoming buildbot provide will go a long way here as well. There are some other ways we can get cheap/easy QA to help accelerate the pace of development and merging.

Anyway, I'm optimistic. There's a lot of work to be done but we're definitely on the right path toward making the flashrom codebase easier to work with and more accessible so that fewer users/developers will see a need to fork.