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.ja...@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.ja...@gmail.com > > _______________________________________________ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > >
_______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community