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: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
