into all that sweet talks about 'tell a story' and extended description of the patches...
DST was released more than a week ago with two-page extended description of the ideas, implementations, features and use cases for the distributed storage. Each file was separately introduced with description of the content and rough usage cases in the project.
Guess the result? We talked a little with Arnd Bergmann and Benjamin Herrenschmidt about thread pools, mainly that it could be good idea to push it separately, and that likely David Howells' slow_work patches will be pushed into the kernel as a thread pool implementation.
I will rebase against 2.6.28 and resend DST and POHMELFS today. Interested people are invited to the appropriate maillists to ask the questions and discuss the needed features.
Even when it's not Christmas you can't rely on instantaneous reviews. The fact that people are engaging and bits are making their way in seems to indicate some success too...
The whole process relies a lot on cooperation and goodwill; you need to bear in mind that people are people and that maintaining relationships is important here.
I just show that the whole process is based not on the technical arguments.
When was the last time that you yourself reviewed someone's code on a project you don't know anything about and aren't very interested in? Or just reviewed a big heap of code you actually are a bit interested in, but not directly involved? Maybe you expect too much of others, others that mostly just work on their own projects just like you. It's sad that not more people review each other's work, but that's how it is.
And of course the process isn't wholly based on technical arguments. If someone comes with a new feature which is implemented perfectly, that on itself is not enough reason to do anything with it.
Indan
I always review the code when I'm added to the copy, and otherwise frequently when it is not very specific to some hardware.
For the recent weeks I can easily call 3-5 big enough projects.
Then it must be even more frustrating that almost no one bothers to review your work. :-(
Indan
Of course not; the whole process is fundamentally about people as much as code. You can't demand anything from anyone and in any case half the goal of the code is a human communication thing as an implementation thing.
To be honest, the fact that you're being a bit confrontational about it probably isn't helping either - if you create the impression that you're difficult to deal with it's not going to get you moved to the top of the code review pile.
might not always be the right choice to achieve a goal. You also can't, however, expect a good coder to be a twice as good politician. A project in need of good and very good and excellent developers has to be aware of that and invest in a development-process that keeps frustration on a reasonable scale. And when the core-devs of a project like the linux kernel fail at this point, then there is a significant problem, which pretty much justifies "being a bit confrontational" - it's actually one of the best things that can happen to it - would anyone notice brilliant but frustrated people silently turning their back on linux?
It probably is a mistake to think that the development-process is anywhere near as good as linux itself. The people in charge are just developers. Sure they're somewhat experienced, but it is the greatest challenge for any organisation to keep up with its own evolution, even if it DOES dedicate resources to reviewing the process. But if it does not, and even seems to be following the assumption that it'll work out in the future just because it did in the past, then it's a lot more likely to fail, no matter how brilliant on a technical scale its product might be in the present.
Can the scalability of the kernel-development process keep up with the size and complexity of the project? The need of "being a bit confrontational" on part of someone like Evgeniy is an indication of something going wrong. Such a guy is an asset, and if he'd contribute to anything I was in charge of I'd not be unwise enough to ignore (many of) his contributions while happily debating similar stuff with my buddies.
You don't need to be a particularly good politician here - much of the standard advice on getting things merged is semi-technical anyway. For example, things about the production of patches like producing smaller patches are as useful for bisection as they are for code review purposes. The rest is all fairly standard interpersonal stuff rather than any great political skill.
The "Evgeniy is being a bit confrontational" thing isn't something that needs to be done in order to get things merged - it's an issue that's causing difficulty in getting things merged. Getting confrontational is rarely likely to help, it's going to annoy the people it's directed against and tends not to make any friends among bystanders either and discourage them from helping. A less confrontational approach will tend to work better, if only by helping ensure that people other than the relevant maintainers pick up the patches and work around anyone who's actually being obstructive.
I'm not saying everything is 100% perfect but (having been involved in the merge of a new subsystem and driver work over a fair chunk of the kernel including some difficult driver submissions recently) it's much better than it's being portrayed - there's certainly an awful lot of review activity going on, even if it'd be nice to get more eyeballs on some things.
Никому твои поделки не нужны, смирись уже, неудачник! :)
А мне пох :)
А чего тогда описываешь каждый файл? :-) От нечего делать?
Чтобы люди знали, что это такое, и как это работает.