Source Code Info
From BUGwiki
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:
- A new release is delivered to QA
- 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.
