Source Code Info

From BUGwiki

Jump to: navigation, search

Contents

Overview

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 bugcamp.net'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: https://github.com/buglabs/. 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.

oe-buglabs

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.

bug-osgi

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

bug20-2.6.35-linaro

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

dragonfly

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://bugcamp.net/bug/branches/R2.0/

BUG code for the next major release

Code intended for the next major BUG release goes into:

svn://bugcamp.net/bug/trunk

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:

svn://bugcamp.net/bug/branches/username/descriptive-branch-name

SDK code

Just about any SDK change should be made in trunk

svn://bugcamp.net/dragonfly/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.

svn://bugcamp.net/dragonfly/testing

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

svn://bugcamp.net/dragonfly/tags/releases/M.m.r

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

svn://bugcamp.net/dragonfly/branches/my_awesome_fixes

I want to see the source for a given release

The BUG releases for 2.0 and above

svn://bugcamp.net/bug/tags/releases/R2.0 

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

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

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.

trunk

This represents the next major release.

qa

This represents the next minor release.

See Also

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox
Print/export