Em Mon, 11 Mar 2019 14:29:14 +0200 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> escreveu: > > > We actually reverted it, but it caused a huge confusion and produced > > > lots of discussions. We lost several active developers: people that > > > were not happy by the 9000 lines patchset stepping on everyone's feet > > > and people that were not happy by reverting it. > > > > Do you happen to remember any details? Did that "reverting" for instance > > involve rolling back to the state before the offending patch after more > > comments had been done? > > I'd like a more detailed version of that story too. It's hard to comment > on this particular example without knowing what happened. You can take a look at the lore archives in 2008. There are lots of threads from that time related to it. There were even some discussions at LKML. I won't myself review the past, as those were very painful days. Unfortunately, on that time, we weren't logging the IRC discussions. A lot of the heat happened there. > > That said, I feel this is not overly important. The DRM folks have proved > > this model works. Still I agree this is good to remember and document, but > > I don't see us getting into such situation _even if_ we'd switch to a > > similar way of working. > > Agreed. I don't think the "9000 lines revert" is relevant anymore as > such. What matters is how to keep existing and attract new developers, > by making the linux-media subsystem attractive and easy and pleasant to > work with. No. What's relevant is that we tried a multiple committers model in the past worked fine for 3 years, but it didn't survive to the first crisis. I'm OK to make the subsystem more attractive, provided that we won't do the same mistakes. So, any change should happen on baby steps, and on a way that it won't repeat the problem where a single developer would be able to make everybody else unhappy. > > > > Some opined that we do not have a bottleneck in reviewing patches and > > > > getting them merged whilst others thought this was not the case. It is > > > > certainly true that a very large number of patches (around 500 in the last > > > > kernel release) went in through the media tree. > > > > > > > > It still appears that there > > > > would be more patches and more drivers to get in if the throughput was > > > > higher. > > > > > > I'm not so sure about that (if we expect good quality patches), > > > specially while we don't have any automatic testing tool to > > > double check some stuff. > > > > I agree. To help improving the process from here, we do need automated > > testing. I don't think anyone has really even argued against adding > > automated testing. > > It won't be enough though. Testing is crucial to scale, but isn't a > substitute for review, it won't solve the review bottleneck by itself. I agree. > > Considering the amount of coverage in the meeting as well as the interest > > in general, it's just a question of time until we have something quite > > usable. > > > > > As a result of those discussions, One of the things that we've agreed > > > there is to give trees at LinuxTV for more active developers that > > > we trust enough to skip a sub-maintainer's review. > > No, please. *Nobody* *ever* should have review bypass rights, there is > no single exception to that rule. I fully agree we should get more > people on-board and give them trees on linuxtv.org, but that's not about > skipping review. This is what it was agreed there, and it applies only to drivers, not to the subsystem's core. We can review such policy on a next media summit. In any case, I take a look on all patches I receive. If I notice something that I believe it would require sub-maintainers review, I'll forward the pull request to a sub-maintainer. Thanks, Mauro
