Difference between revisions of "BEEBS"
m (Branch Management - Remove deleted branches.) |
m (Branch Management: Remove table, expand no release branches.) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 12: | Line 12: | ||
== Branch Management == | == Branch Management == | ||
| − | We currently have | + | We currently have just two branches on github, <tt>beebsv2</tt> and <tt>master</tt>. |
| − | + | In the past most development work has taken place on <tt>beebsv2</tt> but in the future all development should be performed on <tt>master</tt>, any changes that are pushed to <tt>beebsv2</tt> will be merged back into <tt>master</tt>. At some point soon(ish) the <tt>beebsv2</tt> branch will be deleted. | |
| − | + | === Pushing To <tt>master</tt> === | |
| − | + | ||
| − | + | Only push back to the official github repository once work on a feature is complete. All changes pushed should be complete, self contained changes, that introduce no regressions. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Creating New Branches === | === Creating New Branches === | ||
| − | + | Any new branches should only be created in the official BEEBS github repository if the branch is likely to be of use to a typical BEEBS user. If you need to share feature development branches then this should be done by forking the BEEBS repository (on github) and pushing the development branches to the fork. These will then be merged back into <tt>master</tt> on the official repository once the feature is complete. | |
| + | |||
| + | === Release Tags and Release Branches === | ||
| − | + | When it's time to make a release a release branch will be created on github branching off <tt>master</tt> any release specific commits can be made on the branch, and the branch will then be tagged with the release tag. | |
== Release Planning == | == Release Planning == | ||
Latest revision as of 14:17, 12 August 2014
Contents
Introduction
BEEBS is the Bristol/Embecosm Embedded Benchmark Suite, there's a blog post discussing BEEBS here.
Downloading And Building
The code is available on github. Clone the github repository and read the README file for details on how to build.
Note: Currently most of the interesting development is being done on the beebsv2 branch, you might want to switch to this branch before trying to build.
Branch Management
We currently have just two branches on github, beebsv2 and master.
In the past most development work has taken place on beebsv2 but in the future all development should be performed on master, any changes that are pushed to beebsv2 will be merged back into master. At some point soon(ish) the beebsv2 branch will be deleted.
Pushing To master
Only push back to the official github repository once work on a feature is complete. All changes pushed should be complete, self contained changes, that introduce no regressions.
Creating New Branches
Any new branches should only be created in the official BEEBS github repository if the branch is likely to be of use to a typical BEEBS user. If you need to share feature development branches then this should be done by forking the BEEBS repository (on github) and pushing the development branches to the fork. These will then be merged back into master on the official repository once the feature is complete.
Release Tags and Release Branches
When it's time to make a release a release branch will be created on github branching off master any release specific commits can be made on the branch, and the branch will then be tagged with the release tag.
Release Planning
Release 2.0
Currently planned for release August/September 2014.
The issue tracking for version 2.0 is on github, everything with the v2.0 milestone label is currently schedules for release 2.0.
The high level goals for the 2.0 release are:
- Remove unhelpful brenchmarks. Some of the benchmarks compile away to practically nothing, these should be deleted.
- Ensure wherever possible a GPL header is in place.
- Ensure that as many of the tests as possible build on the supported targets. Any tests that don't build should be baked into the exclude lists for that target, a user should not have to figure out which tests are not suitable for a supported target.
Release 3.0
Currently planned for release sometime after version 2.0.
There's a milestone setup for this release on github any issues for this release can be tracked there.
The high level goals for this release are:
- Add support for running the tests...
- On a variety of target boards.
- Using different testing strategies, for example, measuring run time, energy used, size of compiled binary.
- [ MAYBE ] Have the tests self verify themselves.
