[flashrom] Future flashrom development (Stefan's PoV I)

[David Hendricks]

On Wed, Oct 18, 2017 at 10:31 AM, Nico Huber <nico.h at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/flashrom/attachments/20171019/311194d2/attachment.html>