Permalink
Browse files

Remove docs (moved to xcore.github.com)

  • Loading branch information...
1 parent cfaf77b commit 96c39458434875cdc6953c93ae5ead25c3d628a3 @davelxmos davelxmos committed Apr 27, 2011
@@ -1,13 +0,0 @@
-About XMOS Technology
-=====================
-
-It's worth learning something about XMOS technology, XC and the Xcore open source projects. If you don’t understand the syntax of the language, common XC idioms, and the code that already exists in the Xcore open source projects, it will be difficult to make a contribution. You don’t have to know every in-and-out of the language and the architecture, but the Xcore open source projects is probably not appropriate as the first place to write XC code.
-
-Here's some sources of information - there are also some tutorials built into the tools.
-
-* `XS1 architecture specification <https://www.xmos.com/published/xmos-xs1-architecture>`_.
-* `Programming XC on XMOS devices <https://www.xmos.com/published/programming-xc-xmos-devices>`_.
-* `Tools User Guide <https://www.xmos.com/published/tools-user-guide>`_.
-* `Tools download <https://www.xmos.com/products/development-tools>`_.
-
-You'll find more on the `XMOS support website <http://www.xmos.com/support>`_.
@@ -1,17 +0,0 @@
-About the Community
-===================
-
-The Xcore open source project is licensed under `hardware <https://github.com/xcore/Community/raw/gh-pages/HardwareLicense.txt>`_
-and `software <https://github.com/xcore/Community/raw/gh-pages/SoftwareLicense.txt>`_ derivatives of the The University of Illinois/NCSA Open Source License. Some of the community members are members of XMOS staff, while many others are students, people running their own company, academics, or simply excellent volunteers who are interested in building quality stuff.
-
-The following pages should help you to understand the how the community is set up:
-
-* `The XMOS open source manifesto <http://www.xmos.com/open-source/manifesto>`_ (hosted on http://www.xmos.com) describes the aspirations and contributions that XMOS has for the community
-* :doc:`Roles-in-the-community` defines the special responsibilities of certain roles.
-
-If you don't find what you are looking for, please go to the `Xcore open source project user forum <https://www.xcore.com/forum/viewforum.php?f=32>`_ and post a question.
-
-.. toctree::
- :hidden:
-
- Roles-in-the-community
@@ -1,21 +0,0 @@
-About the Repositories
-======================
-
-The following pages describe what you will find in the Xcore open source project repositories.
-
-* Unlike many open source projects, there are many different types of repository. :doc:`Classes-of-Repository` describes the different types of repo you will find here and their structure.
-* :doc:`Repository-usage` describes how to obtain repositories, import them into the XDE and build projects using the code in them.
-* :doc:`Repository-management` describes how to create a new repository, naming convention and how repository status is derived.
-* :doc:`Versioning` describes how to version tags and releases on your repository.
-* :doc:`repo-index` provides an index of the current repositories, their status and releases.a
-
-If you cannot find what you are looking for, please post to the `Xcore open source project user forum <https://www.xcore.com/forum/viewforum.php?f=32>`_.
-
-.. toctree::
- :hidden:
-
- Classes-of-Repository
- Repository-usage
- Repository-management
- Versioning
- repo-index
View
@@ -1,8 +0,0 @@
-Applications
-============
-
-An application typically comprises at least:
-
-* A main-function
-* Reference to a number of modules that are to be used
-* An XN file describing the hardware on which the application runs, or it references a standard hardware design.
@@ -1,23 +0,0 @@
-Classes of Repositories
-=======================
-
-Unlike many open source projects, the Xcore open source project consists of many different classes of design, and we expect the number of classes may also grow over time. Each class may have its own conventions - for example, creating a v1 release of a software component will have a completely different set of requirements to the release of a v1 printed circuit board. There may be other differences relating to how a project is built and tested etc.
-
-The following lists the different classes that we currently use and/or expect in the future. The links are to pages which describe attributes that they share in common, which could relate to build systems, test infrastructure, versioning etc. These restrictions enable the use of automated build and regression systems, which we can all use to interpret the status and maturity of development projects:
-
-* :doc:`Software-components` are bits of code that can be used in applications. They are written for other developers, and can be integrated by other developers. Software components may require a specific peripheral device on one or more I/O ports.
-* :doc:`Applications` are programs that are designed for an end-user. An application may use code form one or more Software components. Applications are often written for a particular hardware platform that incorporates specific peripheral devices on specific I/O pins.
-* :doc:`Hardware-designs` are schematics and or gerber files that specify a design that incorporates one or more XCores. Hardware designs often have a port-map stating which device is connected to which I/O port, and a network description.
-* :doc:`Tools` are programs that are used by developers to create software and/or hardware. Example tools are assemblers, debuggers, and compilers. Some tools will not be hosted in github, because they have a home elsewhere (for example, the LLVM compiler).
-
-Follow the links above to find out more, or, to contribute your views in how the community should manage this diversity, post to the `Xcore open source project user forum`_
-
-.. _Xcore open source project user forum: https://www.xcore.com/forum/viewforum.php?f=32
-
-.. toctree::
- :hidden:
-
- Software-components
- Applications
- Hardware-designs
- Tools
@@ -1,19 +0,0 @@
-Contributing to documentation
-=============================
-
-Another area where you can help out if you’re not yet ready to take the plunge to writing code is with documentation. Either this wiki, or repository documentation.
-
-The Xcore open source documenation
-----------------------------------
-
-This documentation is stored in the
-`Community repo <http://github.com/xcore/Community>`_. You can raise a
-fork and raise pull request against it. It uses `xdoc <http://github.com/xcore/xdoc>`_ to build the documentation.
-
-Design documentation
---------------------
-
-Design documentation for specific repos is contained in those repos themselves.
-
-
-
@@ -1,77 +0,0 @@
-Contributing to the codebase
-============================
-
-When you’re ready to take the plunge, one of the most helpful ways to contribute to the Xcore open source projects is to actually submit source code. Here’s a step-by-step listing of the things you need to do to make this a successful experience.
-
-Learn the Language and the Framework
-------------------------------------
-
-Learn at least something about XMOS technology, XC and the Xcore open source projects - there are some pointers in :doc:`About-XMOS-technology`. Guidelines and examples of each class of open source repository can also be found in :doc:`Classes-of-Repository`.
-
-Install git
------------
-
-The Xcore open source project uses git for source code control. The
-`git homepage <http://git-scm.com/>`_ has installation instructions. If
-you’re on OS X, use the `Git for OS X installer <http://code.google.com/p/git-osx-installer/>`_. If you’re unfamiliar with git, there are a variety of resources on the net that will help you learn more:
-
-* `Everyday Git <http://www.kernel.org/pub/software/scm/git/docs/everyday.html>`_ will teach you just enough about git to get by.
-* The `PeepCode screencast <https://peepcode.com/products/git>`_ on git ($9) is easier to follow.
-* GitHub offers links to a variety of git resources.
-* `Pro Git <http://progit.org/book/>`_ is an entire book about git with a Creative Commons license.
-
-Pick a repository and Fork the Source Code
-------------------------------------------
-
-Unlike many open source projects, the Xcore open source project
-consist of many repositories of multiple types. We use the
-Fork-And-Pull model - once you have found one that you are interested
-in contributing to, you need to `create a fork <http://help.github.com/forking/>`_.
-
-Write Your Code
----------------
-
-Now get busy and add your code to the project (or edit the existing code). You’re on your fork now, so you can write whatever you want. But if you’re planning to submit your change back for inclusion in the Xcore open source projects, keep a few things in mind:
-
-* Get the code right
-* Follow community best practice
-* Include tests that fail without your code, and pass with it
-* Update the documentation
-
-Follow the Coding Conventions
------------------------------
-
-Each repository can be expected to have its own conventions, at least initially. Please be consistent with the conventions already established in any given project. In time, the community may develop more general and more widely applicable guidelines.
-
-Use the community licenses
---------------------------
-
-First - you need to have filled out and clicked through the
-`contributor license agreement <https://www.xcore.com/OpenSourceAgreement>`_. This protects the community from bogus contributions and ensures that code is safe and easy for everyone to reuse. If you've already done this and your latest contribution conforms to the requirements, you can skip this step.
-
-Use (or at least link to) the licenses - there is one for `hardware
-<https://github.com/xcore/Community/raw/gh-pages/HardwareLicense.txt>`_
-and one for `software <https://github.com/xcore/Community/raw/gh-pages/SoftwareLicense.txt>`_. Don't forget to change the copyright to your name or organisation.
-
-For example, if you don't want to copy the license into the top of your source code, here's a lightweight alternative::
-
- // Copyright (c) 2011, <insert copyright holder here>, All rights reserved
- // This software is freely distributable under a derivative of the
- // University of Illinois/NCSA Open Source License posted in
- // LICENSE.txt and at <http://github.xcore.com/>
-
-In this case you should also place the appropriate license in a LICENSE.txt file at the root of your repository.
-
-Pull Request
-------------
-When you’re happy with the code on your computer, you need to do a
-`pull request <http://help.github.com/pull-requests/>`_. This (politely!) asks the maintainer to pull your changes in your fork, into the origin repository.
-
-Iterate as Necessary
---------------------
-
-It’s entirely possible that the feedback you get will suggest
-changes. Don’t get discouraged: the whole point of contributing to an
-active open source project is to tap into community knowledge. If
-people are encouraging you to tweak your code, then it’s worth making
-the tweaks and resubmitting.
View
@@ -1,15 +0,0 @@
-Hardware Designs
-================
-
-Open Hardware is an important component of open firmware, especially for a widely applicable horizontal technology like XMOS processors.
-
-Hardware repos are the place to park your schematics, gerbers, pinout definitions and so on. Project repos can then refer to both component, application and hardware repos to pull it all together. Its quite possible that some users might love your board design but have little interest in the firmware originally written for it, so it makes sense to separate these aspects of projects.
-
-There will be two main kinds of hw\_ repo:
-
- * A hardware design that is designed for use with the
- `XCore Open Source Hardware Platform <https://github.com/xcore/hw_slicekit_system>`_.
- * Other hardware designs
-
-The former can be considered the hardware equivalent of a compliant Software Component, in that standards for interoperability and documentation will apply. The latter is completely freestyle.
-
View
@@ -1,6 +0,0 @@
-SPHINX_PROJECT_NAME=XCore Community Documentation
-VERSION=0.1
-DOXYGEN_DIRS=
-SOURCE_INCLUDE_DIRS=
-XDOC_DIR ?= ../../xdoc
-include $(XDOC_DIR)/Makefile.inc
@@ -1,28 +0,0 @@
-Participating in the Community
-==============================
-
-This section discusses the various ways that you may contribute to the project. Firstly:
-
-* If you are not already a member of the Xcore community, please
- go to http://www.xcore.com/) and sign up - we are using the forums there for discussions.
-* If you do not already have a github login, then you are going
- to need one of those too - it is free and you can do it at https://github.com/signup/micro. At the moment, there is no link between your xcore login and the github repository (yawn), so please (please) update your profile on xcore to identify who you are on github.
-
-You are now in a position to make a real difference. Even if you don’t feel up to writing code yet, there are a variety of other ways that you can contribute, from reporting issues to testing patches to contributing documentation:
-
-* :doc:`Reporting-an-issue` describes how to report an issue with a repository
-* :doc:`Resolving-existing-issues` describes a great way to get started with community contribution
-* :doc:`Contributing-to-documentation` describes how to contribute to community and design documentation
-* :doc:`Contributing-to-the-codebase` describes how to make a contribution to one of the existing repositories
-* :doc:`Repository-management` describes how to create a new repository
-
-Last but not least, please remember that despite the online nature of the Xcore open source project and the human contact abstraction that results from that fact, it is important to realize that there are real people at the end of all contributions. Treat all other community members as you would expect to be treated. Review the contribution, not the contributor; don't annoy others, and don't become easily annoyed yourself.
-
-
-.. toctree::
- :hidden:
-
- Reporting-an-issue
- Resolving-existing-issues
- Contributing-to-documentation
- Contributing-to-the-codebase
@@ -1,10 +0,0 @@
-Planned Developments
-====================
-
-The community could benefit from several features:
-
-* Automated builds, where repositories are automatically built regularly (eg, daily), registering build failures.
-
-* Automated regressions, where repositories are automatically tested regularly (eg daily), logging test failures and other metrics (code coverage for example).
-
-Outcomes of these may help to determine long term stability and quality of the repositories, and will therefore assist community members in deciding whether to include the products of a repo in their own design. Any results will be summarised on the [[Repository status page]].
View
@@ -1,22 +0,0 @@
-Reporting an issue
-==================
-
-The Xcore open source project uses the built-in github issue tracking capabilities (primarily for bugs and contributions of new code). If you’ve found a bug in any of the repositories, this is the place to start. Bugs in most recent versions of a design are likely to get the most attention. Also, the xcore team is always interested in feedback from those who can take the time to test the head of the mainline.
-
-Creating a Bug Report
----------------------
-
-If you’ve found a problem with a repository, you can start by checking existing issues to make sure that the issue hasn't already been reported. If it hasn't, click on the "issue" button in the github repo dashboard. At the minimum, your ticket needs a title and descriptive text. But that’s only a minimum. You should include as much relevant information as possible. Submitting a testcase that shows how the expected behaviour is not occurring and/or proposes a fix is always appreciated.
-
-There is no attachment model, but you can easily fork the repository
-you are submitting an issue to, and provide a link to the fork, which
-would appear under your own public github account. Any changes,
-additional test etc required to highlight the problem can then be
-applied in the fork. See `this github help page <https://github.com/blog/270-the-fork-queue>`_ for more details.
-
-Then don’t get your hopes up. Unless you have a “Code Red, Mission Critical, The World is Coming to an End” kind of bug, you’re creating this ticket in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the ticket automatically will see any activity or that others will jump to fix it. Creating a ticket like this is mostly to help yourself start on the path of fixing the problem and for others to confirm it with a “I’m having this problem too” comment.
-
-What About Feature Requests?
-----------------------------
-
-If there’s a new feature that you want to see added to an Xcore repository (or indeed a new component or design), you’ll need to write the code yourself – or convince someone else to partner with you to write the code. If you enter a wishlist issue in a repo with no code, you can expect it to be marked “invalid” as soon as it’s reviewed. There is however, nothing to stop you creating a new forum topic enquiring politely about the roadmap for a specific component.
Oops, something went wrong.

0 comments on commit 96c3945

Please sign in to comment.