SHR future and way for better stability

Mon Dec 5 16:46:00 CET 2011

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

/****************************************
* *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
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmoko.org/pipermail/community/attachments/20111205/9f9c507d/attachment-0001.htm>