[U-Boot] [PATCH] M28: GPIO pin validity check added

[Robert Deliën]

Hi Wolfgang,

> What do you mean?  Which message do you claim I have omitted?  And
> where?

Oh, no, I'm sorry; That's not how I meant it. I didn't mean 'drop' as in 'omit',
but as in 'passing'.

> 3 hours?  Hm... I think it should be possible to read enough git
> documents and tutorials in one hour to get at least a basic
> understanding of git and import and export from / to a SVN repository.
> Add another hour for some practical experiments with a simple test
> setup. Add another hour for doing it with your real data...

True. There's probably a lesson in there somewhere, in hindsight.

> Do you understand the benefits and importance of a common coding
> style in a big project with many, many contributors?

Oh yes! In my own code, I always include the indent command with an
argument set in the comments. I require people to run that before checking
in their code.

> That's exacty the reasoning I hear always in such situations - and it
> always and unavoidably leads into the well-known pattern that we never
> have the time to do things right, but we always have the time to do
> them twice.

With managers it's always easier to claim time at the end of a project, when
there isn't any time anymore. At the beginning they just want to see
something work quickly.

> Then use another MUA.  There is tons of them.

Yet none of them uses the proprietary Exchange protocol to connect to
coorporate mail servers.
And honestly: People's allergy to inappropriately broken lines hardly
seems a problem worth solving. There's always another intollerance.

> Working in a big project is never easy, especially not when doing the
> first steps into a long-runnign community that has (out of necessity)
> highly optimized it's communication.  The removal of communication
> overhead may easily be (mis-) taken as unkindliness.

True, yet in my experience this efficiency is easier put aside to
express dissatisfaction than it is to express kindness.

> It is important to adjust your own expectations: unless you add a
> really cool new feature or fix a really nasty, long-hunted bug, you
> will probably never receive any explicit praise when you submit a
> poatch - even if it is technically perfect and works like a charme.

As said, I don't and didn't expect that. But I don't expect to get
'flamed' either.

I remember Haralt Welte speak at CELF, complaining about
semiconductor manufacturers not supporting Open Source and big
corporations only leaching and not contributing.
Next time I hear him speak, I will be the first at the mic to explain
him that if employees would mail as 'efficiently' as is done on
some mailing lists, we'd have a real nasty atmosphere in the
office. And that it's this atmosphere that's making corporations
think twice, not unwillingness to contribute.

Seriouly; I've show it to my colleagues and they said I was nuts trying
over and over again. And perhaps I am, because this way I don't
enjoy my work.

> On the other hand, you can be pretty sure that eveny minor issues like
> CondigStyle violations (say, this TAB versus spaces issue) will be
> pointed out without mercy, even if you have submitted the same trivial
> patch already a number of times before.

For those there are rules. I tend to fix those along making changes to a
file. You guys seem to prefer to have separate patches for those, but I
doubt if anybody's going to spend time just on cosmetics.

> This is not meant personally - it is a necessary optimization of the
> process that tries to minimize the efforts spent in later stages.

Perhaps. But there're also people trying to lift their own importance just
by commenting. I see this in meetings every day, but there at least I
get to roll my eyes ;-)

> Basic rule: never take such comments personally, always stick to the
> raw facts.  Expect that the only purpose of the reviewer is to help to
> improve the quality of the code.

Same rule applies on the other side: Never make comments personally.

> But that's nearly twice as many characters to type, and probably
> much less memorable :-)

Clubbing somebody takes even less characters and is even more
memorable (if stopped in time :-).
Yes, it takes a couple of extra keystrokes, but that's all it takes and I
think they're worth the effort in the long run. 

> I am
> sure that Marek does so, too.

Marek is a good guy, no argument about it.

> It's unfortunate that we cannot add
> polite embellishments and lengthy explanations with every message we
> send.  But there is simply no time for it.

I don't agree: I think it doesn't take more than a couple of extra
keystrokes to take off the harsh edge, to be constructive or even to show
some encouragement. No more than it takes to be hars or to discourage
people.
Perhaps I expected a bit too much. A bit disappointing after evangelizing
Open Source and convincing management about the importance of
contributing,

> This is a highly specilize
> technical channel, and the thing we really care about (and are
> willing to spend time for) is the technical progress of the project.
> 
> Never take this personally. Even if we are terse and sometimes harsh,
> we never intend offence (well, usually not ;-)

The Time Nuts mailing list is even more specialized (about high accuracy
time keeping), but on that list people tend to _more_ polite than in real
life, just to prevent hat.

Thank you for your time, Wolfgang. I fully understand if you don't take
the time to respond.

With kind regards,

        Robert.