[oe] IRC discussion about stable branch - 25.03.2009 12:00 GMT

Fri Mar 27 16:48:19 UTC 2009

Hi

Below is summary of our meeting. I know that this is far from being 
perfect but it should show our thoughts.

Definition: OpenEmbedded stable branch is metadata. What users do with
metadata is their choice. We will work on making it buildable.

-----------------------------------------------------------------------

1. 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.

Types of changes:

a) change touches core system (which is anything in tested images or
   classes/)
b) change touches only machine which you maintain
c) change touches only your distro and and it builds
d) 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.

Format of patches: "git format-patch" ones. 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.

-----------------------------------------------------------------------

2. 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.

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.net 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.

-----------------------------------------------------------------------

3. 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.

-----------------------------------------------------------------------

4. 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.

-----------------------------------------------------------------------

5. list of stable branch maintainers

We will need at least 2-4 maintainers. During OpenZaurus times we did
most of development is such team so I think that this is total
minimum.

We need to list who maintains which machines/distros/recipes. So if
at91sam9263ek fails for Joe then he will ask me why it did that and
ask for fix.

List of developers which wants to be maintainers for stable branch:

- Marcin 'hrw' Juszkiewicz  - own company and Bug Labs Inc.
- Philip 'Crofton' Balister
- Marco 'mckoan' Cavallini  - Koan Software

-----------------------------------------------------------------------

6. Creation of stable branch

Stable branch will be created and published at the end of March 2009.

Branch will also contain last release of BitBake tool.

As branch name we chosen "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).

-----------------------------------------------------------------------

Thats all - please share your thoughts and ideas. We are open for
developers who wants to maintain own machines, distros, recipes.

Regards, 
-- 
JID:      hrw at jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20090327/b898221b/attachment-0002.sig>