Lack of Specifications (was my work...)

[Carsten Haitzler (The Rasterman)]

On Fri, 06 Jun 2008 09:14:56 +0100 Andy Green <andy at openmoko.com> babbled:

indeed - but the question is.. not going forward, but what do we have NOW.
freerunner is the end result of some wonderful inbreeding from an originally
windows mobile phone product not actually intended to run linux or anything
open - but it does now. you'd be right for... gta04 or beyond, but as long as
the spec ALSO defines your hardware... it's un-fun to try and meet it by..
changing hardware :)

i don't disagree - don't get me wrong. i'm just being morose and just saying
"well... this is what we have... what is the easiest thing to change right
now... hardware? low level firmware? or a spec someone has come up with
recently? :)

absolutely - in the future spec and hardware should be a thing that is an
interactive process - spec is there, hardware says "we can/can't do it and how
it can be done, and what it will cost". same with software. cost is just the
way of saying "it can't b done, but man that feature is going to cost a fortune
to add". or featues are no-brainers. who knows. depends on the spec.

in the end hardware affects the spec, and the spec affects hardware. you don't
have a one-way street.

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> | On Fri, 06 Jun 2008 07:35:00 +0100 Andy Green <andy at openmoko.com> babbled:
> |
> | Well there is nowhere a spec that says the LED needs to do ANYTHING...
> :) so
> 
> Actually the guy who specifies our products sent out a mail on an
> internal list asking for this functionality, which I unwisely stepped up
> to deliver.  I should've just sat on my hands.
> 
> | even the LED is superfluous. we should ignore it. (as such i don't see
> an mpu
> | being needed to do anything with the LED while charging - why? we
> don't need to
> 
> This pretty nicely makes my point, we should not be arguing at this late
> stage about simple device behaviours that should have been specified
> from the start.  This is a huge morale suckage that puts us in a place
> that actually doing anything that has to make any assertions into any of
> the huge undefined spaces invites nothing but armchair opinions about
> how it should have been done differently.
> 
> | in the end we dont have a spec. we have an existing platform we are
> stuck with
> | - for better or worse. if anything software should simply adjust to it
> and make
> | do. don't try and do things the hardware just won't be good at. some
> things are
> | raw requirements for the hardware, and we just can't ship without it,
> others
> | are entirely soft. :)
> 
> This is not a way forward.  The lack of adequate marching orders affects
> things like the build system as I mentioned that is a pure software
> issue already.
> 
> In particular when it comes to the next platform, we can participate in
> specification formulation but ultimately once that is done, the decision
> about MPU or not falls out of the needs of a truly detailed functional
> spec, not out of your personal opinion formed some distance from, eg,
> pcf50633.c.
> 
> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkhI8gAACgkQOjLpvpq7dMpZ9wCfVuZabfu2mQFunUdnfDXJJ+D0
> Ks4An2EUBp30xxVHYm/XMEz5etZIObDu
> =6V6F
> -----END PGP SIGNATURE-----


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>