Too many lords, not enough stewards
Too many lords, not enough stewards
Posted Feb 2, 2018 1:11 UTC (Fri) by airlied (subscriber, #9104)In reply to: Too many lords, not enough stewards by neilbrown
Parent article: Too many lords, not enough stewards
Now if that developer worked for a company where nobody had a preexisting relationship with you that was able to reach out, how would have it had ended?
I do agree be like James in doing this sort of thing, but also can't we remove James from this story and work it out ourselves and end up in a better place?
(Log in to post comments)
Too many lords, not enough stewards
Posted Feb 2, 2018 1:40 UTC (Fri) by neilbrown (subscriber, #359) [Link]
This was a long time ago so I could be wrong, but I'm fairly sure there was no pre-existing relationship. I think I knew of James, but I didn't know him. I was working at UNSW at the time, and he managed to find my phone number on the university web site.
> but also can't we remove James from this story and work it out ourselves and end up in a better place?
I'm not sure what your point is. Yes, it would be lovely if we could all be nice to each other, but just wanting it doesn't make it happen, any more than wanting code to be bug-free isn't very effective. We all have tools at our disposal which can improve code, and others which can improve community interactions. Some we know about, some we don't - yet.
Having a third party be a mediator, either proactively or by invitation, can help in all sorts of ways. Wanting to "remove James from the story" is a bit like wanting to "remove 0-day from the story": it is discarding a valuable tool.
Too many lords, not enough stewards
Posted Feb 2, 2018 1:53 UTC (Fri) by airlied (subscriber, #9104) [Link]
I'm not trying to make a point, I'm trying to get more in-depth knowledge on how you'd react if you replaced James (who I'm sure you knew was a kernel maintainer even if not personally) with a random manager in a random company.
Maybe we do need some sort of process to deal with developer<->maintainers butting heads with some sort of other contributor being asked to stand in and help work out the details of the problem.
I know Linus has always stated that people don't have to interact with him to work on the kernel, you can work with someone else to get your code merged via their trees, maybe we need that for every level of the hierarchy, maybe we have it but nobody knows how to engage it properly.
Too many lords, not enough stewards
Posted Feb 2, 2018 7:18 UTC (Fri) by error27 (subscriber, #8346) [Link]
Like if things seem to be getting heated we could call in a referee. Sometimes it's not even a flame war, but just a discussion about if the code is buggy where there is a clear answer. If a referee could look at it and give a third opinion that would help.
Back when I was a total programming newbie, I found a sleeping under spinlock bug and reported it to the author. "Are you sure you want to call schedule() while you're holding a spinlock?" The developer was also a newbie and replied "Yes". I told him it would trigger a warning. So then he wrote a patch that messed with accounting to temporarily disable the "sleeping with lock held" warning. This was before we used version control and anyway I was a newbie so I didn't know anything about how patches were merged or who maintained what. I just kept on getting more and more alarmed and annoyed by this terrible code and the other dev was annoyed that I wouldn't leave him alone. Eventually Alan Cox stepped in and told us both to cool it and fixed the bug. It was a totally obvious technical debate that became a personal flame war because I didn't know how to get someone else involved.
Email is tricky. Al Viro once criticised me for being too mean to someone. I deal with a lot of newbies so I wasn't even annoyed when I wrote the email. I thought I was giving good advice "Don't change the code if you aren't sure what the right fix is". But apparently it came off as "Go away forever". That's a simple thing to apologize for that. Al was a useful referee in this case.
Escalating every issue to the TAB is too much and anyway by point it reaches that level you're probably already too traumatized and sick of being a kernel dev.
Too many lords, not enough stewards
Posted Feb 3, 2018 10:36 UTC (Sat) by jani (subscriber, #74547) [Link]
> Sometimes it's not even a flame war, but just a discussion about if
> the code is buggy where there is a clear answer. If a referee could
> look at it and give a third opinion that would help.
Personally, I've found that group maintainership models help with this. If one maintainer ends up in a collision course with a developer for whatever reason, the other maintainers can (and are expected to) chime in. To calm down the discussion, to offer insights and other points of view, maybe take over, offering the first maintainer a break and the developer a fresh start, and so on. Whatever works. Well before the conflicts escalates.
Also as a maintainer, I think it's a luxury to be able to sanity check my decisions with my peers, and to ask for help when I'm frustrated or overworked etc. And to get a straight answer when needed to the question, "Am I being a jerk?"
Too many lords, not enough stewards
Posted Feb 3, 2018 19:47 UTC (Sat) by rodgerd (guest, #58896) [Link]
Too many lords, not enough stewards
Posted Feb 3, 2018 20:43 UTC (Sat) by jani (subscriber, #74547) [Link]
Oh, the full disclosure I failed to add: I've been working with Daniel on transitioning parts of drm and Intel graphics to group maintainer models for the past several years. He has moved on from maintainership, and now we have one maintainer trio for i915 and another trio for "drm misc", with shared maintainer tools, documentation, and similar processes. I think it's been a great success.
Too many lords, not enough stewards
Posted Feb 2, 2018 11:49 UTC (Fri) by l1k (subscriber, #112260) [Link]
Maybe we do need some sort of process to deal with developer<->maintainers butting heads with some sort of other contributor being asked to stand in and help work out the details of the problem.
I had a public dispute a year ago with Bjorn Helgaas over a reverted patch. Out of the blue, Rafael Wysocki reached out both on- and off-list and calmed the situation in a diplomatic way.
It absolutely blew my mind that Rafael, who maintains multiple subsystems and I imagine must be extremely busy, took the time to intervene. It restored my faith in the community and my motivation.
I agree we may need a lot more of such activities.
And in my view, this also validates danvet's observation that very much not "only technical" issues are topical.
Too many lords, not enough stewards
Posted Apr 6, 2018 20:47 UTC (Fri) by bhelgaas (guest, #73603) [Link]
In a nutshell, someone had bisected a "keyboard & mouse unresponsive" regression to http://git.kernel.org/cgit/linux/kernel/git/torvalds/linu... ("PCI: Add runtime PM support for PCIe ports"), which I had merged. I did not know how to fix the regression other than by reverting the patch, so I posted a revert as an interim measure while hoping somebody would be able to do a better fix.
The revert was in linux-next for a while, but I dropped it after about a month when we learned that http://git.kernel.org/cgit/linux/kernel/git/torvalds/linu... ("drm/probe-helpers: Drop locking from poll_enable") fixed the regression, so the revert was never merged to mainline.
I was too hasty in putting the revert on my for-linus branch, and I apologize for that. My intent was to be responsive to the end-user who had spent quite a bit of time and effort isolating and reporting the issue.