SHR future and way for better stability

Klaus 'mrmoku' Kurzmann mok at mnet-online.de
Mon Dec 5 21:31:15 CET 2011


Hello Cristian,

On Mon, 05 Dec 2011, Cristian Gómez wrote:

> Hi Martin, thanks for the updates, I just reflashed my FreeRunner yesterday
> with latest packages from Testing (I want a reliable phone, but at the same
> time one in wich I can play around with learning porpouses and SHR gives me
> that instead of Android) . I want to test latest changes on a partition on
> SD and have shr-core on NAND, I have a question related to this and Qi and
> I'll post about it if I can't figure it out on my own.

> I post this to say thanks to you guys for giving us such an amazing distro
> that suites just fine for plenty of us, I have a question too, Android
> ready phones (let's say LG Optimus One) has the capability of running SHR??
> as I'm planning to buy one

unfortunately no. We have no Android based phone working 100% yet. You
could check
http://wiki.shr-project.org/trac/wiki/Android%20Porting%20Guide to get
an idea of what is needed to be done.

> /****************************************
> * *Don't Worry.......Be Linux!!!!*
> * Cristian Gómez Alvarez
> * Ingeniero en Sistemas y Computación --- Universidad de Caldas
> * Almera Information Management
> * Comunidad de Software Libre Manizales
> * Linux User #463617
> * Mi Blog: http://cristianpark.sehablalinux.com
> *********************************************/


> 2011/12/2 Martin Jansa <martin.jansa at gmail.com>

> > Hi,
> >
> > in last few days we were talking a lot about state of shr-testing,
> > shr-unstable, shr-core and how to improve stability and usability for
> > our users while not slowing down development in our latest version which
> > is shr-core.
> >
> > For details and reasons you can read log from #openmoko-cdevel (13:30)
> >
> > http://logs.nslu2-linux.org/livelogs/openmoko-cdevel/openmoko-cdevel.20111201.txt
> >
> > In the end everybody agreed that we don't have manpower to maintain 3
> > flavors
> > of SHR which are:
> >
> > shr-testing:
> > There were only 2 maintainers of shr-testing. Sebastian Spaeth for
> > shr-testing2009 and Thomas Zimmermann for shr-testing2010 and 2011.1.
> > There was discussion about more fixes for shr-testing, but nobody sent
> > patches for
> > http://git.openembedded.org/openembedded/log/?h=shr/testing2011.1
> > so that they could be applied in standard shr-testing feeds.
> > From my perspective shr-testing lacking so far behind shr-unstable and with
> > known issues is not better then "tested" images and feeds from
> > shr-unstable.
> >
> > shr-unstable:
> > This was based on master branch of openembedded (today called OE-classic)
> > so there was a lot of changes every day which sometimes caused unstable
> > telephony or unusable UI. It was caused mostly because of very limited
> > testing between building it on SHR buildhost and users getting it from
> > shr-unstable feeds by opkg upgrade.
> > But since July 2011 the development in OE-classic was slowing down becase
> > everybody was moving to new layered structure of oe-core/meta-* (google
> > yocto project for more info and fancy video).
> >
> > shr-core:
> > Originaly started in March 2011 as my experimental pet project to
> > evaluate new layers like oe-core/meta-oe, but later all remaining SHR
> > and FSO developers switched from shr-unstable to shr-core too and now
> > we have very lively meta-smartphone repository with BSP layers for our
> > beloved phones and layers for FSO, Aurora and for SHR as distribution.
> > Some stuff from old shr-unstable is still missing and sometimes it's
> > changing too fast for average end user who depends on working telephony.
> >
> > So today we've decided to try something else. Instead of trying to
> > maintain 3 different flavors of shr, we will try harder to provide best
> > experience with shr-core and hopefully migrate all remaining users of
> > shr-testing or shr-unstable to it soon (and then we can rename it to
> > shr-stable :)).
> >
> > Starting with next build we won't push the build output directly to normal
> > feeds, but only to "staging" feeds for testers which decide to try newer
> > versions.
> >
> > It works like this:
> > 1) http://build.shr-project.org/shr-core nothing will be changed in this
> > feed before it's tested by multiple users from staging feed.
> >
> > 2) http://build.shr-project.org/shr-core-staging/ will contain one
> > directory
> > for each major feature we want to test (like EFL or FSO upgrades) or
> > sometimes
> > just rotated weekly when there isn't something major or "dangerous".
> >
> > Each directory has by 3 digit name which identifies the feed (lets call it
> > NNN).
> >
> > Each NNN directory has info.NNN file (and info -> info.NNN symlink) where
> > you can
> > read on which revisions was this feed started, which commits were used
> > during
> > populating this feed and when this feed gets closed (or lets say marked as
> > ready
> > for testers). You can also read how all our branches looked when it was
> > closed.
> >
> > Currently there is 001, 002 and latest.
> > 002 is still getting more stuff from live build, so it wasn't "closed" yet.
> > When we decide that there is enough stuff for testing and the feature is
> > complete, we'll close 002 and redirect build output to new 003.
> > Latest link points to latest but _closed_ feed (so usually highest -1)
> > which
> > is currently 001.
> >
> > If you want to help testing, then best way is to prepare 2nd partition
> > (not the
> > one you're using for daily phone you depend on) and redirect default
> > shr-core
> > feeds to latest closed:
> > sed -i 's#shr-core#shr-core-staging/latest#g' /etc/opkg/*-feed.conf
> > or of course you can lock it to whatever number you want to test later
> > ie: sed -i 's#shr-core#shr-core-staging/007#g' /etc/opkg/*-feed.conf
> >
> > Also you should also download info file from selected directory so you'll
> > know
> > what you are testing after latest link is moved to newer feed.
> > wget http://build.shr-project.org/shr-core-staging/latest/info
> >
> > Then you can upgrade with opkg or reflash to newer image (if images are
> > available
> > in staging area too).
> > opkg update && opkg upgrade
> >
> > Now you can test whatever is important for you (telephony, music, video,
> > ...)
> > and if you're happy with new testing feed you should report it on our wiki
> > http://www.shr-project.org/trac/wiki/Stabilizing
> > there will be table for each NNN feed and you should say there if you're
> > fine with
> > it moving to default public feed or if you have found some issues with it,
> > bug
> > number from http://www.shr-project.org/trac/report where you've reported
> > those
> > issues would be great and it would be fantastic if you also include in
> > that report
> > which NNN feed was last known to work for you and first one where it was
> > broken.
> > That's where those info files you've downloaded will get handy.
> >
> > After some not-yet-known number of testers which marks the NNN feed as
> > working
> > it will be rsynced to default feeds and everybody will get it.
> >
> > This whole mechanism is to provide most reliable default feeds while
> > keeping all
> > development and of course developers in one SHR flavor.
> >
> > This is _only_ for runtime issues, it won't help with build issues which
> > still
> > need to be reported against master in our trac and we'll try to fix them
> > asap.
> >
> > 3) There is also http://build.shr-project.org/tests/shr-core/ which
> > points to really
> > "live" build and normally shouldn't be used (you can call opkg update when
> > there is
> > incomplete feed or whatever....), so please ignore this feed unless you
> > really
> > know what you're doing.
> >
> > Ideas, comments and most importantly patches are very welcome.
> >
> >                                       JaMa on behalf of whole SHR team
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
> >


-- 
Klaus 'mrmoku' Kurzmann



More information about the community mailing list