On Sun, Apr 05, 2015 at 04:46:26PM -0400, David Miller wrote: > From: Roland Dreier <roland@xxxxxxxxxx> > Date: Sun, 5 Apr 2015 07:51:08 -0700 > > > On Sat, Apr 4, 2015 at 10:15 PM, Or Gerlitz <gerlitz.or@xxxxxxxxx> wrote: > >> Indeed. No maintainer voice makes it kind of impossible for > >> discussions to converge. What happens over the last years is that when > >> there's no easy consensus on matter Y, everyone stops breathing and > >> wait to see what happens on the rc1 night, b/c Roland doesn't spell > >> his view/preference (nor exposes his for-next branch till the last > >> minute, see now) many times it seems more as coin flipping. > > > > To me this attitude shows a failure of the community. If I need to > > make every decision, then that doesn't scale. People can ask > > questions a lot more easily than I can answer them. > > No, you need to step in and be the benevolent dictator when people > have their thumbs up their asses and can't make up their minds, > otherwise things grind to a halt. Agree. As a community we don't need the subsystem maintainer to just applies patches that don't have any discussion. Anyone can do that. We need someone that guides potentially good patches to success and keeps the whole code base on track. I don't think you understand how deep the problem Or is describing goes. People have no idea what you want to see, what you will accept and everytime they ask they get silence. Or worse - remeber this? http://www.spinics.net/lists/linux-rdma/msg21114.html You drive-by-NAK'd Barts's patch and then completely ignored Doug's follow up, the entire series just died out, and that patch is still not applied. This isn't a failure of the community. There is a pretty clear expectation of what a subsystem maintainer should do. Greg KH codified some of it in this presentation: https://github.com/gregkh/presentation-linux-maintainer/blob/master/maintainer.pdf Start at page 119: What I will do for you: So, finally, you created the perfect patch series, took all review into account, and sent it correctly, without corrupting the patch. What should you expect from me, the subsystem maintainer? Review your patch within 1-2 weeks Some subsystem maintainers try to get to patches even faster than this, but with travel and different conferences, the best that I can normally do is about 1-2 weeks. If I don't respond in that time frame, just ask what is going on. I have no problem with people asking about their patch status. Sometimes patches end up getting dropped on the floor accidentally, and if I'm being slow I have no problem with being called on it, so don't feel bad about checking up on it. But please wait 1-2 weeks, don't be rude and send a patch at night, and then in the morning send a complaining email asking why it wasn't reviewed already. This happens more than you want to know. Offer semi-constructive criticism Let you know the status of your patch I have a set of scripts that I got from Andrew Morton that will email you when I apply your patch to one of my development trees saying where it has been applied and when you can expect to see it show up in Linus's tree. There is no reason that all kernel maintainers shouldn't do this, and it's nice to see that more and more are. But, I know from personal experience, there are maintainers in this room that I send patches to and I never know what happens to them. A few months later I will see them show up in Linus's tree, usually after I forgot about them. That's not acceptable, and you should not allow this, push back on your subsystem maintainer to use something like this, to keep you informed. Andrew's scripts are public, as are my variations of them, for everyone to use. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
