SHR future and way for better stability

[Martin Jansa]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openmoko.org/pipermail/community/attachments/20111202/0104312e/attachment.pgp>