Source Code Info

From BUGwiki

Jump to: navigation, search



Software for BUG comes in a few main categories: kernel, oe/build system, osgi bundles, sdk, and web. Of these, some are up at github, others (for legacy reasons) are in our own privately hosted subversion repository. Both github and's subversion repositories are public for reading, but requires access to be granted by Bug Labs for checking in. This page describes the layout of the github and subversion repositories, and the check in procedures for various projects.

github Layout

At the top level is our buglabs organization. Browse the projects here: The layouts and descriptions for the individual projects are pretty self-explanatory.

As of Bug SW R2.1 the kernel, web code, osgi, oe build system and sdk are all in our github account.


This is the base for the Open Embedded build system, which is used to compile and create the bug disk image for the BugBase YT. This contains primarily build recipes that call other repositories (bug-based, or outside repositories) to fetch and build components.


This repository contains all of the code for the OSGI integration layer for interaction with java.


This contains the BugBase YT kernel image which is the heart of the BugBase YT's functionality.


This project contains code to build the Eclipse tools for building the BugLabs IDE tools.

SVN Layout

SVN is no longer used for Bug Labs development. For R2.0 and R1.4 reasons, it may still be accessed from time to time for patches or minor updates.

I have code to check in. Where does it go?

BUG code that fixes a current minor release

99.9% of code ends up in trunk. Our release process includes a branch/tag of trunk, then a QA cycle, then if necessary, another branch/tag. All code intended for release goes into trunk.

When development is ready to issue a new RC to QA, trunk is tagged/branched, perhaps modified slightly to pull all code from within this branch, and arrives at svn://

BUG code for the next major release

Code intended for the next major BUG release goes into:


Experimental Code or Code for some unknown future release

For experiements and other code that may or may not make it into a release, a developer branch should be created. An example:


SDK code

Just about any SDK change should be made in trunk


If you plan to work over time and have things broken, then create a custom branch (see below).

If we're in a testing cycle and the change is a bug fix, the changes should be made in the testing branch.


When testing is over and the code is ready for release, a tag is made with the release number


At that time, the testing branch is merged back into trunk and deleted.

Any major changes or experimental changes should be made in a custom branch


I want to see the source for a given release

The BUG releases for 2.0 and above


When things change

Designations such as "trunk" remain constant until:

  1. A new release is delivered to QA
  2. A new release is pushed to production

Changes for QA release

Major Release

In a major release the following transitions occur:

bug/trunk is copied to bug/branches/[release version]/qa
[major release +1] becomes bug/trunk

Minor Release

In a minor release the following transitions occur:

bug/branches/[release version]/qa is copied to bug/tags/RCs/[release version]

Changes for production release

If a given RC is deemed production ready, the following change occurs:

bug/tags/RCs/[release version] is copied to bug/tags/releases/[release version]

Where is buildbot getting it's sources from?

Bug Labs buildbot is the build system we use to generate our products. Buildbot contains a number of builders for various products and versions. There are two primary build types.

Build Types


Incremental builds checkout sources but leave existing sources and build artifacts in place. This results in a very fast build process but in some situations can cause the output to be inconsistent with the sources.


Full builds start from a clean slate and build the entire system from scratch, including the cross compiler and other tools. This means it takes several hours, but the resultant binaries are consistent regardless of the build state or state of the tools.

Beyond the build types there are various places where buildbot extracts source from to build a given image or product.


This represents the next major release.


This represents the next minor release.

See Also

Personal tools