Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/30913 )
Change subject: mainboard/intel: Update mainboard UART Kconfig ......................................................................
Patch Set 2:
Btw. regarding the time component. Given how much commits I see that fix something, I'd expect your development to go much faster if you'd introduce new developers into coreboot (or C or whatever) first, and focus more on reviewing. Basically, I see many people buzzing around doing the job that a single one could do if he wasn't busy reviewing nonsense. Long story short, I think Intel, and maybe Google too, has big management issues. It feels like we are back in the '90s when people thought you could quicken development by putting more people into a team.
Let me see if I can understand your assertion:
- development goes much faster if reviews are focused on. You are suggesting people aren't reviewing patches? Reviews enable faster development? I'm not following such logic. I'm also not sure what you mean by "you". Me, specifically?
Talking about "you" Intel+Google, nothing personal. Also sometimes "you" in the sense of (some)one (that's sometimes weird, but what they taught me in English classes).
Anyway, yes, reviews enable faster development (unless only the best would write the code, nobody wants that). Not every review style, though. I mean the kind of review that averts future debugging and digging (e.g. if a commit message tells something useful, you don't have to digg deeper).
Review can also mean to reject something that would turn into a maintenance nightmare.
- Instead of focusing on reviewing the reviewer could write the code themselves? How do those 2 sentiments jive?
I said "could do" not "should do". This was a little personal, because I've really seen you, Aaron, reviewing patches that didn't make any sense before the review. Even if you'd implement the code yourself, I'd still expect a review (much shorter though). So what I meant was that if many buzz around and only few review, there will be congestion. And I think this is what I'm seeing when I look into somebody else' review in the new platform area.
There's imperfect information/knowledge that slowly focuses over time with improved documentation, etc. There's also teams of people who start an effort way before others get involved. I agree things are not perfect, but again, you seem to be coming from a "I am better. I know better. Why doesn't everyone do things the way I want?" approach. It's very immature tbh.
I still don't see where that impression comes from. Sorry, might be that I just suck at self-reflection. I don't remember me saying "this is the way". I can live with negative review com- ments. I can rewrite my patches when somebody tells me what to change. What I can't stand is when things change to the worse until they don't work anymore and when I try to fix it, I get zero feedback before things are merged (and then talked down).
The reality is that we aren't just dealing with a single platform. We deal with multiple designs in parallel while bootstrapping a chipset. That's a lot details and moving pieces. Some of the approaches are in the guise of saving duplication. Things can certainly be improved, but I don't think your current tactic is making the current working relationship better within the community at large.
Well, what would you suggest for future cleanups? When every- body with the information to see potential breakage is too busy to review, shall I just go ahead again and swallow the slights silently?
Also, if you have too tight schedules, that's a communication issue inside your companies.
I one day hope to work in such a perfect situation as yourself.
Not so perfect either, but as you brought it up multiple times, I really hope you can get nicer schedules in the future. It's not that I have all the time in the world for cleanups either. When I started topic:kconfig_mess, it was simply because menu- config rejected to save my .config ;)
I was reminded in IRC how it looks like discussing this in a review. Sorry Subrata, for hijacking your review for this. Aaron, if you want to continue the conversation, maybe just move to direct email.