Additional editing guidelines for distribution manuals (Was: SHR first experiences & user manual)

Marko Knöbl openmoko.marko at
Thu Aug 27 23:48:27 CEST 2009

> i am not sure if you guys really know what you are talking about:
> navit and sms-sentry have been in shr since long time ago. navit
> always needed several tricks to get it working (issues reported) .
I'm aware of that. However I think the guide on using Navit and
sms-sentry should not be in the SHR manual, because these applications
are not specific SHR-applications.
> elementary-alarm issue has also been reported long time ago ffalarms
> providing a working solution, as mentioned in the manual.
This was only an example I mentioned. Being too lazy and too
uncreative to come up with my own example I just used an existing
obsolete issue as an example.
However I think I explained this in a very complicated way. What I
wanted to say with that guideline is: "You can include workarounds for
an existing bug into the manuals if you want to, but please report
this bug to the bugtracking system as well so it can be fixed there as
Another example might clarify this: in the section "Audio: Volume" I'm
told to set control 4 from 110 to 120. If 120 is indeed a better
setting for all phones (I didn't try it) this should become the
default setting in SHR. While I think it's okay to have the SHR manual
explaining how to fix this I think this should also be integrated into
the default installation. Therefore a bug report should be created
which requests that change. If the bug is fixed this section can be
removed from the manual. If the developers decide to leave the volume
at 110 then they will have a reason for that and this part should be
deleted as well. But the current situation is not very good: SHR has
the default volume at 110 and the manual is telling the users to set
it to 120.
> i think we started with the shr user manual with the full knowledge
> that the stuff moves under our feet (see another post few minutes ago
> about someone not being able to download for install). we wanted to
> get a platform for tweaking and updating. rather then making guidelines
> about guidelines, just
> 1) correct factual errors
> 2) help to fix issues so they don't need workarounds
The second point is exactly what I'm trying to do with the new guideline
> also, we still have lots of users who did not install last weeks image
> and run shr with what was available then (two weeks ago).
> the page certainly does need attention, i am only not sure if this is
> the right way to spend time...
> thank you
> Petr
> _______________________________________________
> Openmoko community mailing list
> community at

More information about the community mailing list