Stable
From Openembedded
Definition: OpenEmbedded stable branch is metadata. What users do with metadata is their choice. We will work on making it buildable.
Contents |
[edit] Getting the stable branch
First download the main branch in the usual way
git clone git://git.openembedded.org/openembedded
then take a look at available branches in the main repository
git branch -a
now you can get the stable branch with
git checkout -b stable/2009 origin/stable/2009
and verify the branch where you are working now
$ git branch org.openembedded.dev * stable/2009
[edit] Dealing with changes
First version of commit policy defines types of changes, review process and testing.
Each change require review on mailing list and at least one Ack from other developer (which can be one of stable maintainers or developers which use stable branch). Preferred situation is when both developers do not work for same company.
NOTE: each change to stable/2009 branch has to be present in org.openembedded.dev branch first.
[edit] Types of changes
- change touches core system (which is anything in tested images or classes/)
- change touches only machine which you maintain
- change touches only your distro and and it builds
- any new stuff which not touch tested stuff
Changes of first type will require 2 Acks and one of them must be given by one of stable branch maintainers.
Last type changes are new distros, machines, recipes/classes etc.
[edit] How to share changes
Do your work in local git repository. Commit each change separately (unless there are reasons for bigger changes). Export patches with "git format-patch" command and send them to openembedded-devel mailing list with [STABLE] as subject prefix. This is most easily done as
git format-patch -s --subject-prefix="PATCH][STABLE"
After people have acked the patch, use patchwork to extract a patch and apply it. There is a patch in contrib/patchwork/ which do that.
If patchset is bigger then few patches it would be nice to also give address of git repository which can be pulled to get those changes.
[edit] Testing of changes
Each change should be tested before getting accepted in repository. We will use buildbot software for full (each time from scratch) and incremental builds. This should give us repeatable builds without any user assistance.
It is important to note that we will test for building. Testing on target devices is left for users which can (and should) report bugs if something is not working. More about reporting bugs later in that text.
Example buildbot is run by Marcin Juszkiewicz: http://home.haerwu.biz:8010/
[edit] What is supported
We also will not support whole metadata. There are recipes which are broken in misc ways and not buildable machines. We will provide list of supported machines, distributions and images. Those will be tested for building by buildbots and developers.
Where and how to list what is supported? We got to few options:
- variable in supported machine.conf/distro.conf/recipe
- SUPPORTED file
- website
We also need to support building on some list of host systems:
- Debian stable and testing
- Ubuntu 8.04 and newer
- Fedora
- RHEL/Centos
All depends on availability of testers and requirements of users. This list is not complete - if required new entries can be added.
There was suggestion about creating 'test scripts' which can be used by users to do builds and automatically report success/failure. Something like current tinderbox.openembedded.org service do but with archive and some kind of processing to add results into list of working systems.
We would need stable source mirror. Currently Ångström one looks like best choice - it is driven by our developers and is hosted on LinuxToGo/OpenEmbedded servers.
[edit] Rejecting changes
We will reject changes which will break test builds. If someone will report break of working system due to recent change we can also consider reverting change.
Also changes which were not given for review will be rejected.
[edit] Handling bugs and user support
Handling bugs is a big issue. I think that we will use Bugzilla for it as it good even if not every developer reads it daily.
We should not generate automatic bug reports during builds. What if someone unplugs our build machine from half of internet? will be massreport fetching problems?
The important thing is who is user of stable branch. By users we mean developers which build stable. End users which use results of builds should report bugs to their distro developers (and it is ok to be stable branch maintainer and distro developer at same time).
Life of bug can looks like this:
1. distro developer do build 1.1. put results in distribution repositories 2. end user install updates 3. finds bug 3a. user reports bug in bugzilla 4. distro developer checks bug 4.1. do fix 4.1.1. fix is sent to stable for review 4.2. can not fix 4.2.1. bug is sent to stable
Mailinglist - we will use OE-devel as it is primary one. Distros which use stable branch can use own ones for handling users.
[edit] List of stable branch maintainers
List of developers which wants to be maintainers for stable branch:
- Marcin 'hrw' Juszkiewicz - own company and Bug Labs Inc.
- machines: at91sam9263ek, vortex86sx, qemuarm, bug
- Philip 'Crofton' Balister
- machines: davinci-sffsdr, omap5912osk(if I can replace/fix hw), beagleboard, overo.
- distro: Ångström
- Marco 'mckoan' Cavallini - KOAN sas
- machines: ronetix-pm9263, vortex86sx, at91sam9g20ek
- distro: Ångström, KaeilOS
- recipes: grub, wxwidgets
- Otavio Salvador
- Leon 'likewise' Woestenberg
- machines: amcc460ex, mpc8313e-rdb, mpc8315e-rdb, sheevaplug
- distro: Ångström
- recipes: related kernels, real-time kernels, any recipe I have touched before.
- Koen Kooi
- machines: beagleboard, leopardboard, sheevaplug
- distro: Ångström
- Denys 'denix' Dmytriyenko - Texas Instruments
- machines: omap3evm, davinci-dvevm
- distro: Ångström/arago
- Khem Raj
- machines: omap5912osk
- distro: Ångström, minimal
- recipes: All Toolchains and C libraries
- Tom Rini - Embedded Alley
- recipes / classes: SDK (*-cross-sdk, meta-toolchain*), Canadian SDK related (canadian*bbclass, *canadian*.bb *mingw*.bb)
[edit] Creation of stable branch
Stable branch was created and published at the end of March 2009.
Branch also contains last (1.8.12) release of BitBake tool.
As branch name we chose "stable/2009" and we plan to tag it monthly with "year.month" as tags. Also monthly tarballs of metadata are planned.
Expected life of branch: 1 year and it has to stay on server later. No one will stop developers from working on stable/2009 branch when "stable/2010" will get created. This also can show "stable/2009" with 2012.03 release (some companies require 10 years of lifetime).
Tarball releases: montly with build status attached (which distros, machines were build tested).
