Changes between Version 20 and Version 21 of WikiStart

Nov 23, 2010 10:07:15 AM (10 years ago)



  • WikiStart

    v20 v21  
    1 '''Please make edits in the [ new wiki]! '''
     1= BCCD Releases =
    3 = Welcome to BCCD-NG =
     3        The BCCD release schedule is principally based on a "when it's ready" mentality. New versions are released once a bug fixes or features are complete and tested for functionality. While we cannot dictate exactly when new versions will appear, we can define the process by which new releases come about.
    5 BCCD-NG is an experimental project to extend the ideas behind the [ Bootable Cluster CD], and possibly be used in the next-generation [ LittleFe] clusters. It aims to replace much of the custom scripting in the BCCD with a stock Debian installation that is easier to maintain, and also to be capable of both RAM-disk and hard disk operation.
     5        Each BCCD version number maintains the form X.Y.Z, where X corresponds to significant or fundamental changes, Y corresponds to changes that "add" something, and Z corresponds to changes that "fix" something. Each new version has a corresponding milestone in the BCCD Trac, with which there will be some number of associated tickets. Once all tickets within a milestone are closed a new release will be tagged, a set of ISOs will be generated, and the previous releases will be archived. After being archived, an old build has the potential to not be hosted anymore. That said, the source for every version will still be kept in the repository, making it easy to rebuild an older version if every necessary.
    7 Specifically, the projects goals are to:
     7        Additionally, once a day, a set of ISOs will be generated from the source in trunk at that given moment. These nightly snapshots provide a way for users to play around with the bleeding-edge version of the BCCD and give feedback to the developers on what may or may not be working. Any given nightly snapshot is only available for 24 hours, as it will be overwritten by the subsequent day's build. As such, any bug report must reference the revision number and the day of the build. This information is easily accessible via the command `bccd-version` shipped within the ISOs.
    9  * Automate the installation of a head cluster node.
    10  * Automate the configuration of diskless booting on the head cluster node, allowing any number of client nodes to boot off it.
    11  * Automate the installation and configuration of HPC software.
     9        It is the Release Engineer's duty to ensure that when a new release is being built, that only those tickets referenced by that version's milestone are being released. In order to enforce this and simultaneously allow active development to continue, a temporary branch will be created for the new version and put under a code freeze while changes are verified and tested. These branches will follow the numbering convention "X.Y.ZrcN" where "rc" is short for "release candidate" and N is an integer standing for which release candidate the branch is. After the release candidate is verified, the release branch and associated builds are created.
    13 In short, the project aims to be a turn-key solution to high-performance compute cluster configuration.
     11        With the process described above, each release can be traced down to a well-defined set of changes and therefore make it easier for users to know what's happening and for the developers to know exactly what each release means.
    15 [wiki:Requirements Requirements]
    17 [wiki:InstallInstructions Install Instructions]
    19 [wiki:UserInstructions User Instructions]
    21 [wiki:DevelopmentInstructions Development Instructions]
    23 [wiki:Tests]
    25 [wiki:TestEnv VirtualBox Test Enviroment]
    27 [wiki:TestLog Test Log]
    29 [wiki:WorkLog Work Log]
    31 [wiki:IncludedSoftware Included Software]
    33 User Wikis:
    35  * [wiki:User:Skylar Skylar]
    37 '''Note:''' This is alpha software, and should not even be interpreted as production-quality.
     13        Questions, comments, or concerns about this process should be sent to