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.
Nico
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.