Tom, On Wed, Sep 16, 2020 at 08:07:42AM -0700, Tom Rix wrote: > > 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? Tbh, I don't appreciate the tone you're taking with your emails: Starting a conversation with how disappointed you are is generally not a great way to get people on board with anything. I'll let you know when I need help beyond the reviews, as I already told you earlier in the replies to your off-list emails. I am not generally opposed to the idea of bringing on new maintainers -- Hao has done a great job for the DFL code so far -- but as of now I do not see an immediate benefit (or need) in terms of process to adding more FPGA maintainers. > Are slow reviews the only problem ? Since the FPGA pull requests go through Greg's tree they need to be sent out earlier than a pull request to Linus, if you send out a patchset around rc4 don't expect it to go in in that release if it requires a non-trivial amount of review -- if you have patches just send them. > Which is getting back to my original RFC on how can we improve the amount of content in the releases ? Send patches earlier (ideally start with an RFC if you intend larger changes) and in smaller batches, which will save you time later in the process. - Moritz
