On Monday 25 September 2006 13:16, Dimi Paun wrote:
On Sun, 2006-09-24 at 12:36 +0900, Dmitry Timoshkov wrote:
Everyone who complaints about "problems" with patch acceptance policy seem to claim that, but my impression is that complaints are going from technically incompetent people, who just "feels" that the process can be improved, but can't explain it in developer's language (i.e. in technical words) how.
One thing to be careful about is the ever growing trend of forming a very tightly coupled in-group. It is very easy to happen: most top developers work for the same company, they are extremely competent, and have the technical argument on their side.
Is it, or is it that the culture attracts "yes" men? Considering the text you quoted, who would want to work for CodeWeavers if they do differ in opinion (or, quite frankly, even if they don't)? People are more likely to go where they will be appreciated.
"We know we're right, because we're all very clever and we all agree".
It is way too easy to feel righteous.
The text you quoted exhibits far more serious problems than that.
This is a big problem, as it elevates the (already high) barrier to entry to a dangerous altitude. And the feedback is positive, as people are being put off, the in-group grows tighter, etc.
Indeed. Consider again the paragraph you quoted. Not only is it ad-hominem, it is a classic example of forestalling disagreement. Don't speak up to disagree or you'll be labelled incompetent. The accusation is far more likely to be more an indication of the maturity of its maker rather than a reflection of truth.
If I say I've been coding since I was 14 (in those days home computers had less than 1% penetration in Australia), in assembly language since shortly after that and raw machine code not long after, having memorised the instruction set, then was widely recognised as the most capable Comp Sci student at the top university for Computer Science in the state, and that I only employ people who are proven geniuses, would it make a difference? While true, it's all irrelevant to the argument at hand. The accusation made above is also irrelevant.
There is a valid point being made here - the black hole of patch submission *is* turning away developers. As one anecdote, one person currently on my staff - and note above - tried submitting patches to Wine in a personal capacity and would most likely still be submitting patches, but found the problems being discussed rendered it not worth his effort. I don't have to walk very far to find somebody else with the same opinion of Wine.
The present system turns people off even before you've had time to learn whether they are capable or not.
To my mind, Alexandre is the Roger Federer and Michael Schumacher of software development. He is never wrong.
Everybody is wrong sometimes, although I have noticed that when somebody gets a sufficiently high reputation people stop noticing when they do get things wrong. I say this from the perspective of somebody who is sometimes in the situation of being the person with that reputation. As an example I have had people say to me "it's easy to speak up when you get everything right", to which I have responded that "I do get things wrong, you just don't notice when I do."
Actually, some people arguing in support of the status quo have pointed out that Alexandre sometimes accepts things he previously rejected after an argument being made successfully in favour of a change - in such a case if we are calling things black-and-white wrong or right, then either the first decision or the revised one must be wrong. A rejection cannot be an incontrovertible sign of the wrongness of the contribution.
Of course making an argument in favour of a particular contribution is somewhat challenging, if not impossible, when you're not being told why Alexandre perceives his solution to be better, which seems to be most of the time. Often the difference may be a mere matter of style - Alexandre seems to be more comfortable with copy-and-paste coding than I am, for example - but if it's more than a matter of style the rejection of the patch should give the reason. It saves no time to require people to chase up Alexandre for reasons unless by "saving time" you mean the person doesn't bother and so the change never gets in.
This is even more difficult when you have to guess Alexandre's ideas about how you should properly solve the problem :)
Actually, this is probably 90%+ of the problem. If patch submission weren't a black hole in which it either gets through or you have to go begging for feedback like an errant schoolboy, you wouldn't see nearly the volume of complaints you do.
Worse are the times when you spend considerable time reworking a patch to his specifications and he still won't let it in. One of my staff had this problem, and the answer from Alexandre was that he wasn't going to let *anything* in covering that area no matter how it was implemented until it had been proven in the field (effectively forcing a branch). That's pretty soul-destroying stuff. That staff member resigned a short time later, and while he gave other reasons his frustration with dealing with Alexandre had been showing, and his whole job revolved around improving Wine.
IOW, I think we're missing on an important human aspect of development: the need to compete, and show that you can do it better than the other guy.
This is something that abates with maturity... at least for people who don't get stuck in a One True View Of The World mind-set.
Bottom line, I don't know. At most I can say that sometimes I wish Alexandre would be a bit more impulsive, and just let (a selected few) things in that people want.
I don't think this is necessary, at least