This is an old revision of the document!


A PCRE internal error occured. This might be caused by a faulty plugin

====== Staging tree ====== {{ :bootrom.jpeg?120x96|A boot ROM}} The [[http://git.etherboot.org/?p=gpxe-staging.git|staging tree]] is used to hold contributed patches for review and merging into the [[http://git.etherboot.org/?p=gpxe.git|main gPXE tree]]. It provides a central location for collecting patches submitted via the mailing list. Most branches in the staging tree hold individual features, such as a new driver, and are referred to as "feature branches". Once a feature branch has been merged into the main gPXE tree, it is deleted from the staging tree. ===== Trying out a feature branch ===== You can build gPXE from any feature branch in the staging tree, if there is a particular new feature that you would like to try out. {{:warning.png?50x43 |Warning sign}} Please be aware that all code within any branch of the staging tree is **completely unsupported**. This means that: * code found within the staging tree will not necessarily be merged into the main branch, * code found within the staging tree may be changed in incompatible ways by the time it is merged into the main branch, * you should not rely on code found within the staging tree when building production systems. By helping to debug a feature branch in the staging tree, you will be helping to accelerate the merging of the feature into the main branch! ==== Building from the staging tree using git ==== If you already have a clone of the main gPXE tree, you can access the staging tree by doing cd gpxe/src git remote add staging git://git.etherboot.org/scm/gpxe-staging.git git fetch staging git branch -r -v You should see a whole series of ''staging/feature'' branches, such as staging/3c90x 130e421 [3c90x] 3c90x driver rewrite using gPXE API staging/eepro100 92f2d8c [eepro100] Bring mdeck's eepro100 driver to staging staging/imgauto 1de3f5b [image] Added imgauto command to fetch, load, execute staging/sdsk 89f32b0 [build] Add syslinux floppy image type .sdsk staging/subxfix 5c6a1c6 [build] Fix signed/unsigned division in util/zbin.c staging/undiheader e7ce627 [romprefix] Make replacement UNDI ROM optional You can check out and build any one of these feature branches using git checkout staging/feature make where ''feature'' is the name of the feature branch that you want to try out. ==== Building from the staging tree using rom-o-matic ==== If you are not building gPXE from source, you can obtain a pre-built binary of gPXE for any of the current feature branches from [[http://rom-o-matic.net/|rom-o-matic]]. Please note that this is provided only for convenience; as with all code from the staging tree, these binaries are **completely unsupported** and you should use the code only if you are prepared to help debug it. ###### mdc - please fill in the correct URL for rom-o-matic's staging tree builds ##### ===== Contributing a new feature ===== New features should almost always be placed into the staging tree. This makes it easier to review and merge, and also makes your code instantly available for people to try out. ==== Submitting directly to the staging tree ==== {{ :nic.jpeg?237x222|A network card}} If you already have a shell account on rom.etherboot.org, you can submit code to the staging tree for review and merging into the main tree by doing git checkout master git checkout -b my_feature ... commit changes for my_feature ... git fetch origin git rebase origin/master git push staging my_feature There are some points to bear in mind when submitting code for review: * Each commit should be reviewable as a standalone unit that makes sense from the point of view of the tree as a whole. For example, a new feature branch that requires some changes to the net device core API should contain at least two commits: one commit to change the net device core API (and to fix up all code affected by this change) and one or more commits to then introduce the new feature. * There should be no trace of partially-working attempts, abandoned ideas, temporary hacks, and so on. Commands such as ''git rebase --interactive'' and ''git commit --amend'' can be very useful in tidying up a branch so that it is ready to be pushed to the staging tree. * Each commit must be buildable in its own right. For example, do not introduce a C file in one commit that depends upon a header introduced only in a later commit. * Each commit should be small enough to be sensibly reviewed in isolation. There are no hard and fast rules, but the easier the commit is to review, the sooner it is likely to be merged into the main gPXE tree. After a code review, you may need to make changes to your feature branch. You may find it useful to use the command git rebase --interactive master in order to edit individual commits within your feature branch. Once you have made any required changes, you can push your updated branch using git fetch origin git rebase origin/master git push staging my_feature --force This will bring your branch up to date with any upstream changes, and push the updated branch in to the staging tree. ==== Submitting via e-mail ==== If you do not have a shell account on rom.etherboot.org, you can send patches to the [[etherboot-developers@lists.sourceforge.net]] mailing list. Please generate your patches using git fetch origin git rebase origin/master git format-patch -s --stdout master > my_feature.patch and send ''my_feature.patch'' as an attachment to the mailing list, along with a brief comment describing your patch.


QR Code
QR Code staging (generated for current page)