| Version 14 (modified by tim_abell, 3 years ago) (diff) |
|---|
SHR Maintainer's guide
About this guide
This guide is written to explain how things are supposed to be done, with notes where we currently fall short.
Currently the emphasis is on laying out a method for running (maintaining) the shr testing distribution; as this is where the biggest hole is. Shr-unstable is mentioned for completeness, but it is more part of ongoing bleeding edge development than "maintenance" and should therefore be documented in detail elsewhere. Shr unstable is largely considered here for its role as an upstream source for shr testing.
Shr stable will not exist until the process for shr testing is established so again is only mentioned for completeness and to set out a strategy for the future.
See also
- notes for shr-testing2009.
- how debian does it http://www.debian.org/devel/
- open embedded testing information
- SHR_Architecture
Getting started
Being a maintainer involves being reasonably sure that what you create will build successfully and work for others, so you probably should make sure you can build shr from scratch on your own pc. Start here, doing as much as you feel you need to:
- read http://wiki.openembedded.net/index.php/Getting_started and Building SHR
- create a local copy (following the above instructions)
- check it builds locally
- ideally flash your new image to your neo (from shr-unstable/tmp/deploy/images/)
- point your neo to your home made feeds (I suggest overriding the buildhost ip in /etc/hosts on you neo), and running apache on your build box to serve the feeds (serving up the contents of shr-unstable/tmp/deploy/ipk/)
shr-unstable
- latest commits, likely to regularly break, ideal for collecting bug reports :-)
- already actively maintained
Ideally this will have a clean upgrade through opkg, though there are occasional breakages and workarounds posted to the mailing lists.
shr-testing
Currently only maintained by spaetz (who's been doing a fine job but seems to have gone missing lately).
Based on snapshot of shr-unstable with only bugfixes and somewhat tested improvements pulled in.
Objectives
- Clean upgrade through opkg (has been achieved for a while now, ignoring the fact there haven't been any updates in the last few months!)
- Avoiding breakages that are introduced into shr-unstable.
- Semi-regular addition of interesting/requested new features/packages (after they have been relatively bug free on shr-unstable for a while).
- No experimentation (that should all go into shr-unstable).
- Published version should always build without error (i.e. test locally before pushing).
- Provide smaller / alternate temporary patches that alleviate user pain when the fix on shr-unstable is too radical.
Maintenance
keeping careful eye on commits to http://git.openembedded.org/cgit.cgi/openembedded/log/ is good start
keep up with the mailing lists
subscribe to oe-commits for notifications of new checkins to openembedded (above)
when there are features people need, or there are problems that people are having difficulties with (see mailing lists and irc) then pull new things in as above
- merge/cherry-pick stuff from shr-u branch to shr-t branch
- check it builds locally
- build & test images on shr buildhost and if ok then:
- sync the results to public feeds
shr-stable
as yet not begun, though occasionally requested.
This will likely be a an older version of shr-testing, with only bug fixes and security fixes applied.
Who's who
Potential maintainers
- Tim Abell - (active interest but nothing concrete yet)
- Neil Jerram - expressed an interest on the mailing list
Previous maintainers
- spaetz - ran shr-testing2009
Todo
- documented process for cycling versions (perhaps like debian does where unstable is copied to testing, testing becomes stable, and the old stable goes into maintenance mode, all on a rough schedule)
- documented process (especially communications method for agreeing) for including packages, bugfixes, updates etc.
- information on where shr-t code, patches, bugs, builds, images and packages are hosted and how to gain read / read-write access.
- process for gaining maintainership status
Notes
current difficulties
due to the high right of churn it is currently hard to keep even a testing version vaguely stable, often being faced with a bugfix being presented as a complete rewrite (potentially incompatible with other items thus forcing wholesale package upgrades or introducing new bugs due to immaturity of the new code).
