[Gta04-owner] Updates for gta04 DTS file.

NeilBrown neilb at suse.de
Sun Jan 11 23:22:30 CET 2015


On Thu, 8 Jan 2015 10:32:28 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> Hi,
> 
> 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? 
> 
> Sure.
> 
> > 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.

There is a lot of documentation for newcommers to read.
 Documentation/HOWTO
and
 Documentation/SubmittingPatches

are a good starting point.

I don't know how good they are 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.
> 
> Sure.
> 
> 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.

Yes, that annoys me too.
However it is very hard to keep documentation up to date.  Is missing
documentation better or worse than out-of-date documentation?   I don't know.

When I'm trying to understand code, I read the code (not the patches).  When
something seems particularly strange I often look for the patch which added
the code in the hope of finding an explanation.
The comment with the patch should at least be accurate at the time the patch
was written.  I might then need to see how subsequent changes affected things.

Documentation is hard.  There isn't enough of it (though lwn.net sometimes
posts useful things).  It isn't clear to me that the linux patch flow makes
the situation worse though.


> 
> 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.

There is an economic perspective that is useful here.
There are lots of people with questions and relatively few who are able to
provide answers.  So how can the questioner "buy" attention from the answerer.

One way is to demonstrate competence.  If it is clear that the person asking
the question will understand the answer and doesn't need to be spoon-fed,
then it is a lot easier to answer.  This can be demonstrated by proposing a
partial solution.

Another way is to trigger the "Someone is wrong on the Internet" response.
  http://xkcd.com/386/

Discussing architecture in an open mailing list is really hard.  People with
very narrow perspectives can derail the discussion and waste lots of time.
It can hard to know who to ignore and who to listen to.  As simple metric is
you pay attention to people who are clearly doing work and providing code.


> 
> 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.

This is correct.  I think Linus has described Linux development as
"Evolution, not Intelligent Design".  There is no big plan.  There is just
people working on their own projects and trying to work together.
It can be frustrating to people who like big-picture design, but it appears
that there is no real way to make that sort of approach work.

NeilBrown

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20150112/0cc17840/attachment.asc>


More information about the Gta04-owner mailing list