On Fri, 2005-10-07 at 11:17 -0400, David Boyes wrote: > > Our development model has changed over time. While this was > > true in the early days, we now contribute our changes early > > to the mainline kernel. I agree that while things are in the > > "what do you think" state, we mostly use the more convenient > > communication "go to Martin's office and talk it over" over > > the less convenient one "mailing list". > > Not having the privilege of direct access to Martin's office (although the > few times I've been able to speak with him on the phone, he's had good > suggestions and the discussion has been valuable), I can't argue whether > it's more convenient or not. It's not an option for the rest of us, so I > would argue that it really doesn't scale as a method of working together.
My collegues here in BB certainly have an advantage over the rest of the world in regard to getting my attention. > > That's exactly what should happen. But it is the > > responsibility of the author do drive that discussion. I did > > not see that happen in this case, and it is exactly the same > > what I need to do here in Böblingen to get my code accepted by Martin. > > I think I would politely disagree. If someone posts something and asks for > comments in the appropriate public forum, that is IMHO sufficient pursuit. > If others have difficulties with the approach or comments, I'd observe that > it's the responsibility of the person with the question to contact the > author and discuss -- preferably in public if the issue is sufficiently > important -- why it's not the best solution. Most of us are mature enough to > at least hear someone out if they have a differing opinion on a solution. Hmm, I try to follow the mailing lists but at the end of the day its a matter of time. I try to read lkml, linux-mm, linux-390, linux-arch, binutils, libc-alpha, libc-hacker and some others. Just to post something on e.g. linux-390 does not guarantee that I see it. If you specifically want my comment please put me on CC. > Maybe I'm still a bit of an idealist, but ultimately, though, in my mind, > running code wins. We can always refine a solution - and we will - with the > peer review process, but at the end of the day, there's the fundamental > difference between something that works, and kibitzers. A particular > solution may not be perfect, but something that works is (usually) better > than nothing, and the better technical solution will be determined by field > use and feedback, not be desk checking. And that is where the linux kernel is different. If it just works but is doing "the-wrong-thing" then a solution won't get accepted even if there is nothing better at that point in time. The sooner you accept this, the more work you get done because you safe the time you otherwise spent arguing. There is a reason why not everything that works is accepted: it has to work tomorrow as well, and next month, next year, next decade... Once you added a broken kernel/user interface you are basically stuck. That's why we keep on bitching about user/kernel code split, policy, /proc files and other lovely things. > It's those darn edge cases where we have problems. 8-) > > > Martin is not maintainer of this architecture because he is > > IBMer. He is maintainer, because he does do a good job on > > reviewing other people's work and giving constructive advices > > and because he is really dedicated enough to work overtime > > and do-what-it-takes to get to the best possible soloution. > > Your statement heavily implies that Martin does make a > > difference between contributions from IBM and contributions > > from elsewhere. I don't see that: I frequently do discussion > > with him about ideas and their implementation, and I hear > > "don't do that" or "solve it differently" approximatly once a week. > > I think it is unfair to demand a different maintainer after > > failing to drive the discussion of subject driver towards integration. > > I don't want to seem to disparage Martin -- as you say, he's doing a nasty, > thankless job extremely well, and if I seemed to imply otherwise, then > please accept my apologies. Nothing to apologize about. I developed a thick skin. > What I do see is that the process of his job *is* somewhat impeded by some > of the restrictions he is bound by by virtue of him being an IBM employee. > Not being able to look at and comment on proposed implementations freely is > a problem. Not being able to work with the consolidated repository because > IBM Legal can't figure out how to build the right Chinese walls to keep his > job safe is a problem. Being the "only" pipe into the arch/s390 and > arch/s390x trees is eventually going to be a problem in terms of succession > and workload. As he *is* the only gatekeeper for this architecture, this > seems like something that we -- as a whole community -- should address as a > whole. Yes, there are some restrictions about what I can do. But they aren't as stringent as you believe. For all practical purposes I can comment on any proposed implementation. I can't work at the consolidated repository yet but we keep trying to find a solution. About me being the "only" pipe to the s390 backend: that is just not true. The point here is that you need to have a name in the kernel community to get things accepted for s390 without me. There are numerous examples where that has happened. If someone unknown tries to change something in arch/s390, include/s390 or drivers/s390 I get asked about the change. I usually get asked about changes from well known people as well but there my agreement isn't really required. That is what is meant by being the maintainer. And if something has broken the kernel for s390 then I usually have to deal with it. > One option on the table is to share the responsibility a bit -- it's gotta > be a major hassle for Martin's free time to be the only guy doing this. If > the option of using a external organization like SHARE or WAVV would solve > some of the legal problems, then it's worth the discussion. At least IBM > Legal has some history with those organizations, and has a past model of how > to deal with them. We're not starting from scratch there. And what is solved by that? Bad code is still bad code. To name a new maintainer won't get you anywhere if that person starts to wave through bad code. Maintainership is about trust that only code that matches a certain standard gets accepted and about saying "no" to bad code. > For me, that's the business of what we're doing here in this exchange -- > there is a percieved problem present. This discussion is supposed to explore > options to solving the problem. It's not about Martin failing to do > something, it's about solving the problem, however perceived or real. I > happen to think that a non-IBM voice would be helpful in partially solving > this problem; you have a different perspective. Let's discuss it and find > some middle ground. If that non-IBM voice is a nobody as far as the kernel community is concerned he or she has to spent some considerable time to make himself/herself known to the community before we will see an improvement. -- blue skies, Martin Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
