[Gta04-owner] Updates for gta04 DTS file.
Dr. H. Nikolaus Schaller
hns at goldelico.com
Thu Jan 8 10:32:28 CET 2015
Am 08.01.2015 um 10:11 schrieb Radek Polak <psonek2 at seznam.cz>:
> On Wednesday, January 07, 2015 21:22:42 Dr. H. Nikolaus Schaller wrote:
> > Hi,
> > Am 07.01.2015 um 20:27 schrieb NeilBrown <neilb at suse.de>:
> > > Definitely agree here. To me, the patches are as much a part of the
> > > result as the working code is. The "patch" is the basic unit of
> > > communication between developers.
> > Which is quite a high barrier for new developers… To me it appears that
> > long-term kernel developers are not even aware of this effect.
> Are you avare of git blame command?
> With correctly splitted and commented patches it's invaluable tool - every line of source code is commented with commit message. If you dont split and comment your patches correctly, git blame is useless.
Yes it is a nice tool.
My point is: because this tool is available to us knowledged developers we think that it is easy and patches are very important (Neil said: “basic unit of communication”).
But it makes it difficult for newcomers.
> > It is like looking at your bank account and seeing only the many + and - .
> > Until there is a line “balance” you don’t know if the account is good or
> > bancrupt.
> If you apply the patches, you have the balance. Without good paches you have just the balance and no idea why did you bancrupted.
But without doing the balance calculation after each + or - you don’t know how much you can still spend. I.e. they are
good for analysis why you got bancrupt, but not good to protect you and make wise decisions. For that you need the balance.
I mean with this: the code structure and its understanding does come from the “balance" and not the individual + and -
So commit messages for + and - do NOT describe how the code works in total. I.e. the architecture is hidden.
It is like a mosaic where you look at the individual pieces and how they fit together. And only if you go back you see the picture.
And I observe a tendency to see the commit messages as documentation of the code and there are seveal source files in
Linux where the only comment is the license header… So not code is commented but changes.
This is only my observation that there is IMHO a significant style change which appears to me to be a barrier for newcomers.
And inhibits discussions about goals and software architecture, if the basic unit of communication is a patch.
Neil gave a nice example. He submits patches and asks: I want to do it this way. When asking how he should do it, he rarely gets an answer.
Translated: it is not possible to discuss methods, strategies or architecture. It is only possible to discuss proposed solutions.
Maybe it is because I am a in my deep heart a philosophical scientist who formulates the question first (and even discusses
it) and then looks for answers :)
On the other hand this patch orientation is probably the only way to manage a big community project like Linux. It is like a
very big construction site where it is impossible to have a well published and understood plan. Rather people add what they
need. And it is not necessary to fit it into the big plan as long as it does not break something.
Just my 2ct,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gta04-owner