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 <[email protected]> > > 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] > > -- Klaus 'mrmoku' Kurzmann _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
