kernel defconfig, debugging, preemption, and very noticeable speedups/ debugging

[David Ford]

*brings up MMS*

[huge thread deleted]

i'm not going to be snarky and the below doesn't apply to everyone, nor
every single time.  it is, however, far too common.

i want to remind people that other people, developers for this story,
have different perspectives on what is an acceptable tradeoff and what
is desirable.  i basically dropped the half way written SMS/MMS
application that already supports several very handy features and has
all but rendering support for MMS built in because of the really
negative attitude primarily to MMS and backend interference^H^Hsupport. 
even though i consider my software very much alpha, it's far more
advanced and capable than the existing sms software on FR.

take this as chiding.  you annoy|scare away developers for a lot of
reasons.  people bring up legitimate questions and points about things
on IRC and they get slapped around because someone who is a long time
identity in the channel disagrees.  when was the FR first brought onto
the market?  one might reasonably make the mistake in expecting a stable
and function structure to exist by today.

but people who probably could significantly help make progress find this
enclave to be an unwelcoming group.  if ideas aren't spawned from inside
the tribe, they're unappreciated and disparaged.

documentation should be cleaned up and organized.  pardon, but it's god
awful frustrating to wade through scattered out of date and incomplete
or entirely lacking documentation.  much of what is available, is
written by an "engineer" (a developer who isn't really good at
communicating) who already knows how something works but fails to
document how you get from step 1 to step 17 then skips to step 39.  all
of which applies only to a specific version of something that has
already been deprecated with a wholly rewritten daemon, probably over a
year ago.

sure.  this is a developer phone.  but it's still wrong to make every
new developer struggle insanely to understand how things work
-currently- never mind you the way things worked a month ago.  we don't
even need to bring up the completely naive end user.  i doubt this phone
will ever have a set of software that works, as reliably and as
expected, as something like the iphone, blackberry, droid, etc. 
certainly not with the established guard going on as usual.

people bring up a question on irc and they get yelled at to go RTFM. 
new developers have every bit of right to yell back at you to WTFM. 
people don't gripe for one or two little annoyances.  they start griping
when required things break, frequently.  they gripe when there are
numerous bugs, visible bugs, that don't get fixed for a year or two.  if
there's a lot of griping from "end users" that pisses you off, there's a
reason for it.  your bugginess level has well exceeded average tolerances.

when someone comes up with a new approach or idea and it isn't from the
established guard - it's a bad thing.  apparently.  because the
established guard knows how it should be done.  which is why years down
the road it still isn't doing, still isn't stable, and still isn't
featureful.

it's entirely OK to run on a kernel without any debugging enabled for
most people.  most people are neither kernel developers, nor do they
need to deal with debug information until something breaks.  if
something breaks and affects everyone, it shouldn't have been put into
distribution in the first place.  there's clearly a difference between
development software which might exhibit unexpected bugs or issues, and
software which the developer knows is going to blow up 45 seconds into use.

on the whole, the kernel is normally a very very stable beast.  there's
really not a whole lot different the kernel does on the little FR that
it doesn't do on your desktop.  debugging code removal from the disted
kernel has been brought up before, it just faded away because there
wasn't a nasty irc spat. 

if you want to make progress, stop getting pissed off at at "end users"
when they report mountains of bugs and have complaints, or can't get
something to work.  especially when you dist software which is known to
be buggy or incompatible with the previous version released last week. 
most people bought this phone knowing it has rough edges.  most know
that they know they should be a developer.  however, it's a phone and
most people have a natural inclination to want to use it as a phone. 
especially after paying $400US.

you haven't provided these new people with much if any initial support
in their first experience with the phone or the software.  either by
help or documentation in the software itself, or via a website.

people can go back over the email archives for the past few years and
see this particular type of drama-fest erupt frequently.  nobody wants
to recommend this project to other embedded developers because of this. 
'tis a good way to ensure existing developers keep ripping their hair
out and are barraged by complaints.

please reconsider where you stand and how you treat new or different
ideas and the people expressing them.  they don't need to be dragged
into the rut of how you do things, they need to drag you out of your rut.

-david