All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
To: Alexander Holler <holler@ahsoftware.de>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Alexander Clouter <alex@digriz.org.uk>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
Date: Sat, 09 Apr 2011 10:29:13 +0200	[thread overview]
Message-ID: <1302337753.30783.24.camel@thorin> (raw)
In-Reply-To: <4D9E42E1.1060902@ahsoftware.de>

On Fre, 2011-04-08 at 01:04 +0200, Alexander Holler wrote:
[...] 
> I had a look at what's going on in the OMAP linux world for more than a 
> year now and I think I've seen a lot of the stuff you are referring to.

Others were far longer in in several of these "Linux worlds" ....

> And I think one of the reasons that the mess happened is the same I've 
> got trapped in. Why should anyone try to submit patches if he must fear 
> to get caught in some senseless endless discussion about one line.

Welcome to the world where software is actually really maintained - and
not longer in the easy world of "fork it, hack it up to ship it and be
done with it - except of bugs actually reported by customers who care
enough to get the bug report that far" like it is not uncommon in the
embedded world.

> E.g. requiring people to use NULL than 0 or that stupid discussion now 

You obviously where never forced to bugfix with source where you can
identify the writer of each be the style.

> about the simple patch I've posted. I'm writing whole (readable) C++ 

"readable" is quite subjective. And just because it is readable by you
doesn't imply it is readable for many others. Especially if you actually
wrote it .....

> applications (not crap!) in less time than what's is needed to submit 
> and discuss a small patch for some silly hw.

That's precisely the point: Writing the source is the easiest job.
Maintaining it over years and keeping it clear is hard.

> So for me it's fully understandable why companies don't try to work with 
> kernel people at first. They try to develop innovativ products they can 
> sell, and it doesn't help if their developers would have to fear that 

"Innovative products which actually sell" are neither necessary nor
sufficient to produce maintainable code.
IMHO it it quite the opposite - these companies just want to get their
products built as quickly as possible to minimize the time to market and
get it sold (as in "second place, first looser") and be done with it
(except the sales part of course).
And the vast majority of the software on these products is actually not
really maintained - they have just bugs fixed if they crop up and some
user works hard enough to get the bug report actually to someone who
might fix it.
Existing software is just patched to implement the "new features" far
enough to be usable on that one product - ignoring the big picture of
the upstream with all the features and possibilities.
For the next release/version/product, the old code is plain simply
forked and everyone moves on.

[...] 
> It's one thing to say such to someone you know and work with, but it's a 
> totally different thing to say such to someone you almost know nothing 
> about. And not everybody who hasn't the name of a big company in his 
> email address is a moron.

You have to read more mails on the LKML and you will see, that the
domain name in the mail address help in any direction - neither to avoid
being flamed nor that a patch goes faster in.
Of course, there *are* people out there where it looks like that a
well-known domain name helps - but most of them started to hack on the
kernel and (successfully) submit patches with other domains. Think about
it ...

> Sorry, I'm getting sick having to defend me here against people who like 
> to call others crap and abonimation writing ones just because they have 
> maintainer status or whatever.

The main reason was a pure technical one. Think about it ....

Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at


WARNING: multiple messages have this Message-ID (diff)
From: bernd@petrovitsch.priv.at (Bernd Petrovitsch)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
Date: Sat, 09 Apr 2011 10:29:13 +0200	[thread overview]
Message-ID: <1302337753.30783.24.camel@thorin> (raw)
In-Reply-To: <4D9E42E1.1060902@ahsoftware.de>

On Fre, 2011-04-08 at 01:04 +0200, Alexander Holler wrote:
[...] 
> I had a look at what's going on in the OMAP linux world for more than a 
> year now and I think I've seen a lot of the stuff you are referring to.

Others were far longer in in several of these "Linux worlds" ....

> And I think one of the reasons that the mess happened is the same I've 
> got trapped in. Why should anyone try to submit patches if he must fear 
> to get caught in some senseless endless discussion about one line.

Welcome to the world where software is actually really maintained - and
not longer in the easy world of "fork it, hack it up to ship it and be
done with it - except of bugs actually reported by customers who care
enough to get the bug report that far" like it is not uncommon in the
embedded world.

> E.g. requiring people to use NULL than 0 or that stupid discussion now 

You obviously where never forced to bugfix with source where you can
identify the writer of each be the style.

> about the simple patch I've posted. I'm writing whole (readable) C++ 

"readable" is quite subjective. And just because it is readable by you
doesn't imply it is readable for many others. Especially if you actually
wrote it .....

> applications (not crap!) in less time than what's is needed to submit 
> and discuss a small patch for some silly hw.

That's precisely the point: Writing the source is the easiest job.
Maintaining it over years and keeping it clear is hard.

> So for me it's fully understandable why companies don't try to work with 
> kernel people at first. They try to develop innovativ products they can 
> sell, and it doesn't help if their developers would have to fear that 

"Innovative products which actually sell" are neither necessary nor
sufficient to produce maintainable code.
IMHO it it quite the opposite - these companies just want to get their
products built as quickly as possible to minimize the time to market and
get it sold (as in "second place, first looser") and be done with it
(except the sales part of course).
And the vast majority of the software on these products is actually not
really maintained - they have just bugs fixed if they crop up and some
user works hard enough to get the bug report actually to someone who
might fix it.
Existing software is just patched to implement the "new features" far
enough to be usable on that one product - ignoring the big picture of
the upstream with all the features and possibilities.
For the next release/version/product, the old code is plain simply
forked and everyone moves on.

[...] 
> It's one thing to say such to someone you know and work with, but it's a 
> totally different thing to say such to someone you almost know nothing 
> about. And not everybody who hasn't the name of a big company in his 
> email address is a moron.

You have to read more mails on the LKML and you will see, that the
domain name in the mail address help in any direction - neither to avoid
being flamed nor that a patch goes faster in.
Of course, there *are* people out there where it looks like that a
well-known domain name helps - but most of them started to hack on the
kernel and (successfully) submit patches with other domains. Think about
it ...

> Sorry, I'm getting sick having to defend me here against people who like 
> to call others crap and abonimation writing ones just because they have 
> maintainer status or whatever.

The main reason was a pure technical one. Think about it ....

Bernd
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at

  parent reply	other threads:[~2011-04-09  8:29 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-06 20:35 [PATCH 0/2] ARM: Unify setup for Marvell SheevaPlugs and Seagate DockStars Alexander Holler
2011-04-06 20:35 ` Alexander Holler
2011-04-06 20:35 ` [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size Alexander Holler
2011-04-06 20:35   ` Alexander Holler
2011-04-06 21:44   ` Nicolas Pitre
2011-04-06 21:44     ` Nicolas Pitre
2011-04-06 22:45     ` Alexander Holler
2011-04-06 22:45       ` Alexander Holler
2011-04-06 23:01       ` Nicolas Pitre
2011-04-06 23:01         ` Nicolas Pitre
2011-04-06 23:22         ` Alexander Holler
2011-04-06 23:22           ` Alexander Holler
2011-04-07  2:55           ` Nicolas Pitre
2011-04-07  2:55             ` Nicolas Pitre
2011-04-07  8:55           ` Alexander Clouter
2011-04-07 21:31             ` Alexander Holler
2011-04-07 21:31               ` Alexander Holler
2011-04-07 21:44               ` Alexander Clouter
2011-04-07 21:44                 ` Alexander Clouter
2011-04-07 21:59                 ` Alexander Holler
2011-04-07 21:59                   ` Alexander Holler
2011-04-07 22:08               ` Russell King - ARM Linux
2011-04-07 22:08                 ` Russell King - ARM Linux
2011-04-07 23:04                 ` Alexander Holler
2011-04-07 23:04                   ` Alexander Holler
2011-04-08  7:24                   ` Russell King - ARM Linux
2011-04-08  7:24                     ` Russell King - ARM Linux
2011-04-08  8:38                     ` Alexander Holler
2011-04-08  8:38                       ` Alexander Holler
2011-04-09  8:29                   ` Bernd Petrovitsch [this message]
2011-04-09  8:29                     ` Bernd Petrovitsch
2011-04-10 18:14                     ` Alexander Holler
2011-04-10 18:14                       ` Alexander Holler
2011-04-10 19:29                       ` Alexander Holler
2011-04-10 19:29                         ` Alexander Holler
2011-04-06 23:23         ` Eric Cooper
2011-04-06 23:23           ` Eric Cooper
2011-04-06 20:35 ` [PATCH 2/2] ARM: Remove machine type dockstar (use sheevaplug instead) Alexander Holler
2011-04-06 20:35   ` Alexander Holler
2011-04-06 21:02   ` Nicolas Pitre
2011-04-06 21:02     ` Nicolas Pitre
2011-04-06 21:43     ` Alexander Holler
2011-04-06 21:43       ` Alexander Holler
2011-04-06 22:50 ` [PATCH 0/2] ARM: Unify setup for Marvell SheevaPlugs and Seagate DockStars Nico Erfurth
2011-04-06 22:50   ` Nico Erfurth
2011-04-07  9:20   ` Alexander Holler
2011-04-07  9:20     ` Alexander Holler
2011-04-07  9:37     ` Nico Erfurth
2011-04-07  9:37       ` Nico Erfurth
2011-04-07  9:44       ` Alexander Holler
2011-04-07  9:44         ` Alexander Holler
2011-04-07 17:39         ` Russell King - ARM Linux
2011-04-07 17:39           ` Russell King - ARM Linux
2011-04-08  3:38           ` Alexander Holler
2011-04-08  3:38             ` Alexander Holler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1302337753.30783.24.camel@thorin \
    --to=bernd@petrovitsch.priv.at \
    --cc=alex@digriz.org.uk \
    --cc=holler@ahsoftware.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.