On 9/15/20 2:33 PM, Moritz Fischer wrote: > Tom, > > On Tue, Sep 15, 2020 at 01:58:52PM -0700, Tom Rix wrote: > >> A non trival change takes 8 revisions, with about 1 week per revision. > I don't consider that to be out of the norm, especially if you want > multiple people to give feedback on a changeset. This is a result of the > distributed nature of people working across several timezones. > > I generally prefer to go a bit slower and get it right rather than > having to redo or realize we got the interfaces wrong -- some of which > have to stay stable. > >> Gives us 1 or 2 changes per release. >> >> In the easy case, a new card is in the same family, will have 4 new ip blocks >> >> and a change to glue it all together change, 5 patch sets. > So far I haven't seen that happen that many times. > >> So we can handle 1 or 2 cards year. > Again I haven't seen more than that in the past. >> But if we can cut the review down to 2 weeks, we could do maybe 5-10 cards per year. >> >> >> Then the downside if we do not keep up. >> >> every card has a custom out of tree driver available on a limited set of distros. >> >> which i believe is the current state of things. > Tbh, this is easy to fix as vendor by just submitting the code earlier > and in smaller chunks. People can send out RFCs early and then we can > discuss designs and not just show up with 20+ patch series and expect them > to be merged as is (ideally within 2-3 revisions) even more so if they > span several subsystems. > > The kernel never has cared about corporate timelines, and as vendor if > you care about timely hardware support (and want to avoid out-of-tree > nightmares) start early with your upstreaming efforts. That has always > been the case. > >>>> So I was wondering what we can do generally and i can do specifically >>>> to improve this. >>>> >>>> My comment >>>> Though we are a low volume list, anything non trivial takes about 8 revisions. >>>> My suggestion is that we all try to give the developer our big first >>>> pass review within a week of the patch landing and try to cut the >>>> revisions down to 3. >>> It's unfortunate that it takes so long to get things moving, I agree, >>> but with everything that's going on - bear in mind people deal different >>> with situations like the present - it is what it is. >>> >>> My current dayjob doesn't pay me for working on this so the time I dedicate >>> to this comes out of my spare time and weekends - Personally I'd rather >>> not burn out and keep functioning in the long run. >> I understand, in the past i have worked as a maintainer when it was not my day job, it's hard. >> >> I am fortunate, fpga kernel and userspace is my day job. Over the last couple of months, i have been >> >> consistently spending a couple hours a day fixing random kernel problems as well as getting linux-fpga >> >> reviews out within a day or two so i know i have the bandwidth to devote. >> >> >> So I am asking what else can I do ? >> >> Would helping out with staging the PR's be help ? > As you pointed out above, the bottleneck is review velocity, I don't > know what staging PRs helps with that. > >> Could i move up to a maintainer ? > The problem is I'd still like to review the patches that go into my > subsystem. I appreciate your help with the reviews, and it's been > helpful so far. I don't think having an addtional maintainer will help > with that at this point. We agree slow reviews are throttling the content in the releases. Is this a temporary situation with your work or is it steady state? Are slow reviews the only problem ? Which is getting back to my original RFC on how can we improve the amount of content in the releases ? Tom > > - Moritz >
