Browse Source

Change most in-tree references from SVN to GIT.

Also, talk about "mainline" not "trunk".

The release.txt and release.sh files need more updates.


git-svn-id: svn://svn.berlios.de/openocd/trunk@2825 b42882b7-edfa-0310-969c-e2dbd0fdcd60
tags/v0.3.0-rc0
dbrownell 11 years ago
parent
commit
03c9e48f88
13 changed files with 133 additions and 175 deletions
  1. +1
    -1
      BUGS
  2. +3
    -13
      PATCHES
  3. +29
    -22
      README
  4. +3
    -2
      README.Win32
  5. +2
    -1
      bootstrap
  6. +3
    -3
      doc/manual/primer/autotools.txt
  7. +22
    -73
      doc/manual/primer/patches.txt
  8. +18
    -18
      doc/manual/release.txt
  9. +3
    -5
      doc/manual/style.txt
  10. +19
    -26
      doc/openocd.texi
  11. +3
    -1
      src/openocd.c
  12. +11
    -5
      testing/index.html
  13. +16
    -5
      testing/smoketests.html

+ 1
- 1
BUGS View File

@@ -22,7 +22,7 @@ that may be important.
- If the report is for a regression:
- Include logs for both working and broken versions.
- Find the precise version that caused the regression by binary search.
For example: if testing version 550 works but 600 fail, then try 575, etc.
You can use "git bisect" to expedite this binary search.

If possible, please develop and attach a patch that helps to expose or
solve the reported problem. See the PATCHES file for more information


+ 3
- 13
PATCHES View File

@@ -9,9 +9,8 @@ you're a member, despite what the list info page says.

@section Patch Guidelines in a Nutshell

The patch should be against svn trunk using an SVN
diff. If you use git-svn, a git diff or patch is OK
too; likewise a quilt patch, if you use quilt.
Your patches should be against git mainline. Submit output
of "git diff"; equivalently, quilt patches are OK.

It should be a "good patch": focus it on a single
issue, and make it be easily reviewable. Don't make
@@ -34,18 +33,9 @@ Add yourself to the GPL copyright for non-trivial changes.

To create a patch from the command line:
@code
svn diff >mypatch.txt
git diff >mypatch.txt
@endcode

See: @par
http://svnbook.red-bean.com/en/1.0/re09.html

Remember to use "svn add" on new files first: @par
http://svnbook.red-bean.com/en/1.0/re01.html

If you have a decent SVN GUI, then that should be
able to create and apply patches as well...
@section More Information on Patching

The @ref primerpatches provides a more complete guide to creating,


+ 29
- 22
README View File

@@ -74,13 +74,13 @@ A Note to OpenOCD Users
-----------------------

If you would rather be working "with" OpenOCD rather than "on" it, your
operating system or interface supplier may provide binaries for you in a
convenient package.
operating system or JTAG interface supplier may provide binaries for
you in a convenient-enough package.

Such packages should be more stable than SVN trunk, where bleeding-edge
Such packages may be more stable than git mainline, where bleeding-edge
development takes place. These "Packagers" produce binary releases of
OpenOCD after the developers produces new "stable" versions of the
source code. Previous versions of OpenOCD cannot be used to diagnosed
OpenOCD after the developers produces new "release" versions of the
source code. Previous versions of OpenOCD cannot be used to diagnose
problems with the current release, so users are encouraged to keep in
contact with their distribution package maintainers or interface vendors
to ensure suitable upgrades appear regularly.
@@ -205,7 +205,7 @@ options may be available there:

--enable-maintainer-mode enable make rules and dependencies not useful
(and sometimes confusing) to the casual installer
NOTE: This option is *required* for SVN builds!
NOTE: This option is *required* for GIT builds!
It should *not* be used to build a release.

--enable-dummy Enable building the dummy JTAG port driver
@@ -376,29 +376,36 @@ the following:
Note that on Linux there is no good reason to use these FTDI binaries;
they are no faster (on Linux) than libftdi, and cause licensing issues.

=================================
Obtaining OpenOCD From Subversion
---------------------------------
==========================
Obtaining OpenOCD From GIT
==========================

You can download the current SVN version with an SVN client of your
choice from the following repositories:
You can download the current GIT version with a GIT client of your
choice from the main repository:

svn://svn.berlios.de/openocd/trunk
or
http://svn.berlios.de/svnroot/repos/openocd/trunk
git://openocd.git.sourceforge.net/gitroot/openocd/openocd

Using the SVN command line client, you can use the following command to
fetch the latest version (make sure there is no (non-svn) directory
called "openocd" in the current directory):
Using the GIT command line client, you might use the following command
to set up a local copy of the current repository (make sure there is no
directory called "openocd" in the current directory):

svn checkout svn://svn.berlios.de/openocd/trunk openocd
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd

If you prefer GIT based tools, the git-svn package works too:
Then you can update that at your convenience using

git svn clone -s svn://svn.berlios.de/openocd
git pull

Tips For Building From The Subversion Repository
************************************************
There is also a gitweb interface, which you can use either to browse
the repository or to downlad arbitrary snapshots using HTTP:

http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd

Snapshots are compressed tarballs of the source tree, about 1.3 MBytes
each at this writing.


Tips For Building From a GIT Repository
---------------------------------------

Building OpenOCD from a repository requires a recent version of the GNU
autotools (autoconf >= 2.59 and automake >= 1.9).


+ 3
- 2
README.Win32 View File

@@ -40,7 +40,8 @@ Take note that different Linux distributions often have different MinGW
installation directory. Some of them also put the library and include
into a separate sys-root directory.

If there is a new svn version of libusb-win32, you can build it as well.
When the libusb-win32 repository is more current than its release code,
you could build that instead.

These are the instruction from the libusb-win32 Makefile:

@@ -93,5 +94,5 @@ To use ftd2xx:
--with-ftd2xx-win32-zipdir=/path/to/libftd2xx-win32 \
... other options ...

If you are using the SVN repository, see the README file for additional
If you are using the GIT repository, see the README file for additional
instructions about configuring and building OpenOCD.

+ 2
- 1
bootstrap View File

@@ -20,6 +20,7 @@ autoheader
automake --gnu --add-missing --copy
)

# AM_MAINTAINER_MODE requires SVN users provide --enable-maintainer-mode
# AM_MAINTAINER_MODE requires --enable-maintainer-mode from everyone using
# current source snapshots (working from GIT, or some source snapshot, etc)
# otherwise the documentation will fail to build due to missing version.texi
echo "Bootstrap complete; you can './configure --enable-maintainer-mode ....'"

+ 3
- 3
doc/manual/primer/autotools.txt View File

@@ -22,14 +22,14 @@ cases, a fresh bootstrap may be still required.
@subsection primerbootstrapcures Problems Solved By Bootstrap

For example, the build system can fail in unexpected ways after running
<code>svn update</code>. Here, the <code>make maintainer-clean</code>
<code>git pull</code>. Here, the <code>make maintainer-clean</code>
should be used to remove all of the files generated by the @c bootstrap
script and subsequent build processes.

In this particular case, one may also need to remove stray files by hand
after running this command to ensure everything is rebuilt properly.
This step should be necessary only if the @c maintainer-clean was run
@b after altering the build system files with Subversion. If it is run
@b after altering the build system files with git. If it is run
@b before any updates, the build system should never leave artifacts
in the tree.

@@ -61,7 +61,7 @@ experience errors when running @c make that some files cannot be found
the problems. The isssue is well-known and expected, if unfortunate.

The OpenOCD project requires that all developers building from the
Subversion repository use the @c --enable-maintainer-mode option when
git repository use the @c --enable-maintainer-mode option when
running the @c configure script. This option ensures that certain files
are created during the build process that would normally be packaged in
the distribution tarball. The @c bootstrap script will remind you of


+ 22
- 73
doc/manual/primer/patches.txt View File

@@ -6,10 +6,10 @@ for OpenOCD contributors who are unfamiliar with the process.
@section primerpatchintro Introduction to Patching

The standard method for creating patches requires developers to:
- checkout the Subversion repository (or bring a copy up-to-date),
- checkout the git repository (or bring a copy up-to-date),
- make the necessary modifications to a working copy,
- check with 'svn status' to see which files will be modified/added, and
- use 'svn diff' to review the changes and produce a patch.
- check with 'git status' to see which files will be modified/added, and
- use 'git diff' to review the changes and produce a patch.

It is important to minimize the changes to only those lines that contain
important differences; do not allow stray whitespace changes into your
@@ -20,7 +20,7 @@ patches, and keep the focus to a single logical change.
You can create a patch (from the root of your working copy) with a
command like the following example: @par
@verbatim
svn diff > patch-name.patch
git diff > patch-name.patch
@endverbatim

where @a patch-name should be something that is descriptive and unique.
@@ -29,8 +29,8 @@ The above command will create a patch containing all of the changes in
the working copy; if you want to obtain a subset, simply provide the
list of files to the command: @par
@verbatim
svn diff doc > <patch-name>-doc.patch
svn diff src > <patch-name>-src.patch
git diff doc > <patch-name>-doc.patch
git diff src > <patch-name>-src.patch
@endverbatim

This will create two patches, each containing only those changes present
@@ -56,65 +56,20 @@ submission, sending your patch to the bit bucket on accident.
@section primerpatchpreflight Developer Review

Before sending in patches, please make sure you have updated to the
latest version of the trunk (using <code>svn up</code>) before creating
latest version of the trunk (using <code>git pull</code>) before creating
your patch. This helps to increase the chances that it will apply
cleanly to the trunk. However, the content matters most.

When creating a patch using "<code>svn diff</code>", Subversion will
When creating a patch using "<code>git diff</code>", git will
produce a patch that contains all of the changes in your working copy.
To manage multiple changes at once, you either need one working copy per
patch, or you can specified specific files and directories when using
<code>svn diff</code>. Overlapping patches will be discussed in the
<code>git diff</code>. Overlapping patches will be discussed in the
next section.

The remainder of this section provides

@subsection primerpatchprops Subversion Properties

The Subversion attributes of files can be examined with commands like the
following: @par
@verbatim
$ svn pl README
Properties on 'README':
svn:eol-style
$ svn pl tools/rlink_make_speed_table/rlink_make_speed_table.pl
Properties on 'tools/rlink_make_speed_table/rlink_make_speed_table.pl':
svn:executable
svn:eol-style
$
@endverbatim

@subsection primerpatchpropcrlf Native Line-endings

Subversion checks out files marked with the attribute @c svn:eol-style
set to @c native such that these files contain the default line ending
style of the current host ('\\n' or '\\r\\n'). By using the proper line
endings for different platforms, two different byte streams for the same
file will be produced.

@subsection primerpatchwincrlf Windows Patching Problems

Because of the line-ending functionality, it may be correct when a fresh
patch does not apply cleanly on the Windows platform. This is because
patches are created by SVN with UNIX line endings, so the context and
changes will not appear to match the files with Windows line endings.

In other words, the following command may @b not succeed because @c foo
has its @c svn:eol-style property set to @c native: @par
@code
svn diff foo | patch -R
@endcode

The following series of commands will work: @par
@code
svn diff foo | unix2dos | patch -R
@endcode

This is not a bug.

@todo Does Subversion's treatment of line-endings for files marked with
svn:eol-style=native continue to pose the problems described here, or
has this been magically solved?
@todo Does git's treatment of line-endings behave sanely?
Basically, the repository should use newlines internally,
and convert to/from CRLF on Windows etc.

@section primerpatchseries Patch Series

@@ -132,9 +87,8 @@ simply a matter of taste or familiarity; your mileage may vary.

Packages such as @c patchutils, @c diffutils, and @c quilt are among
those that have proved themselves invaluable for these type of tasks.
Others take their patch management a step further, tracking the
Subversion repository with git-svn and employing GIT conventions and
methodologies for development.
Others take their patch management a step further, using stkgit or
some other framework on top of git.

@subsection primerpatchseriesinterdiff Using @c interdiff

@@ -144,22 +98,22 @@ patches. This command can be used to manage the creation of trivial
patch series. For example, the following sequence of commands will
produce three patches: @par
@verbatim
$ cd openocd-head/
$ svn up && svn st
At revision NNNN.
$ cd openocd/
$ git pull
...
$ <<<start changes for patch #1>>>
...
$ <<<finish changes for patch #1>>>
$ svn diff > series-1.patch # patch #1 is easy
$ git diff > series-1.patch # patch #1 is easy
$ <<<start changes for patch #2>>>
...
$ <<<finish changes for patch #2>>>
$ svn diff > series-1+2.patch # create patch 1+2
$ git diff > series-1+2.patch # create patch 1+2
$ interdiff series-1{,+2}.patch > series-2.patch # 1 ~ 1+2 => #2
$ <<<start changes for patch #3>>>
...
$ <<<finish changes for patch #3>>>
$ svn diff > series-1+2+3.patch # create patch 1+2+3
$ git diff > series-1+2+3.patch # create patch 1+2+3
$ interdiff series-1+2{,+3}.patch > series-3.patch # 1+2 ~ 1+2+3 => 3
@endverbatim

@@ -173,19 +127,14 @@ efficiently than can be managed by hand. For out-of-tree work projects
that require such patch management, @c quilt provides an indispensable
tool for solving the problem.

@subsection primerpatchseriesgit Using @c git

The @c git revision control system provides a tool for tracking
Subversion repositories.

@section primerpatchsubmit Submitting Patches

Write access to the OpenOCD Subversion repository is limited to
Write access to the OpenOCD git repository is limited to
contributors that have demonstrated the ability to produce clear,
consistent, and frequent patches. These individuals are responsible
for maintaining the integrity of the repository for the community.

Thus, commits to the Subversion repository must be handled by one of
Thus, commits to the git repository must be handled by one of
these maintainers.

Patches must be sent to the OpenOCD developer mailing list:


+ 18
- 18
doc/manual/release.txt View File

@@ -26,13 +26,13 @@ formats: <code>openocd-\<version\>.{tar.gz,tar.bz2,zip}</code>. If
produced properly, these files are suitable for release to the public.

When released for users, these archives present several important
advantages when contrasted to using the Subversion repository trunk:
advantages when contrasted to using the git repository:

-# They allow others to package and distribute the code.
-# They build easier for developers, because they contain
a working configure script that was produced by the Release Manager.
-# They prevent users from trying a random HEAD revision of the trunk.
-# They free developers from answering questions about trunk breakage.
-# They prevent users from trying a random work-in-process revision.
-# They free developers from answering questions about mainline breakage.

Hopefully, this shows several good reasons to produce regular releases,
but the release processes were developed with some additional design
@@ -64,9 +64,9 @@ the minor version will @a also be zero (<code>y = 0, z = 0</code>).
After these required numeric components, the version string may contain
one or more <i>version tags</i>, such as '-rc1' or '-dev'.

The trunk and all branches should have the tag '-dev' in
Mainline and all branches should have the tag '-dev' in
their version number. This tag helps developers identify reports
created from the Subversion repository, and it can be detected and
created from the git repository, and it can be detected and
manipulated by the release script. Specifically, this tag will be
removed and re-added during the release process; it should never be
manipulated by developers in submitted patches.
@@ -159,8 +159,8 @@ If T is the time of the next release, then the following schedule
might describe some of the key milestones of the new release cycle:

- T minus one month: start of new development cycle
- T minus two weeks: announce pending trunk closure to new work
- T minus one week: close trunk to new work, begin testing phase
- T minus two weeks: announce pending mainline closure to new work
- T minus one week: close mainline to new work, begin testing phase
- T minus two days: call for final bug fixes
- T minus one day: produce -rc packages and distribute to testers
- T minus one hour: produce final packages and post on-line
@@ -212,20 +212,20 @@ Even with the release script, some steps require clear user intervention

The following steps should be followed to produce each release:

-# Produce final patches to the trunk (or release branch):
-# Produce final patches to mainline (or release branch):
-# Finalize @c NEWS file to describe the changes in the release
- This file is Used to automatically post "blurbs" about the project.
- This material should be produced during the development cycle.
- Add a new item for each @c NEWS-worthy contribution, when committed.
-# bump library version if our API changed (not yet required)
-# Remove -dev tag from package version in configure.in:
- For major/minor releases, remove version tag from trunk, @a or
- For major/minor releases, remove version tag from mainline, @a or
- For bug-fix releases, remove version tag from release branch.
-# Branch or tag the required tree in the Subversion repository:
-# Branch or tag the required tree in the git repository:
- Tags and branches for releases must be named consistently: @par
"${PACKAGE_TARNAME}-${PACKAGE_VERSION}"
- For a major/minor release from the main trunk, the code should be
branched and tagged in the repository:
- For a major/minor release from the mainline, the code should be
tagged in the repository:
@verbatim
svn cp .../trunk .../branches/${RELEASE_BRANCH}
svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
@@ -238,9 +238,9 @@ svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
-# Prepare to resume normal development activities:
- Archive @c NEWS file as <code>doc/news/NEWS-${PACKAGE_VERSION}</code>.
- Create a new @c NEWS file for the next release
- For major/minor release from the trunk:
-# Bump major or minor package version in trunk.
-# Restore version tag to trunk and release branch.
- For major/minor release from the mainline:
-# Bump major or minor package version in mainline.
-# Restore version tag to mainline.
- For bug-fix releases from a release branch:
-# Bump bug-fix version in release branch.
-# Restore version tag to release branch.
@@ -310,7 +310,7 @@ Packaging Commands:

Repository Commands:
commit Perform branch and tag, as appropriate for the version.
branch Create a release branch from the project trunk.
branch Create a release branch from project mainline.
tag Create a tag for the current release branch.

Other Commands:
@@ -338,7 +338,7 @@ affect its behavior:
and it produces archives that are unsuitable for public release.

@note Only the Release Manager should use the @c --live option, as
it will make permanent changes to the Subversion repository that
it will make permanent changes to the git repository that
cannot be undone.

@subsection releasescriptenv Release Script Environment
@@ -371,7 +371,7 @@ use to run the @c release.sh script to produce a minor release.
If the proper environment has been set, the following steps will produce
a new minor release:

-# Check out (or update) the project trunk from the berliOS repository:
-# Check out (or update) mainline from the repository:
@code
svn checkout "${SVN_URL}/trunk" openocd-trunk
@endcode


+ 3
- 5
doc/manual/style.txt View File

@@ -49,7 +49,7 @@ OpenOCD project.
- limit adjacent empty lines to at most two (2).
- remove any trailing empty lines at the end of source files
- do not "comment out" code from the tree; instead, one should either:
-# remove it entirely (Subversion can retrieve the old version), or
-# remove it entirely (git can retrieve the old version), or
-# use an @c \#if/\#endif block.

Finally, try to avoid lines of code that are longer than than 72-80 columns:
@@ -358,10 +358,8 @@ perl script.pl

Maintainers must also be sure to follow additional guidelines:
-# Ensure that Perl scripts are committed as executables:
- Use "<code>chmod +x script.pl</code>"
@a before using "<code>svn add script.pl</code>", or
- Use "<code>svn ps svn:executable '*' script.pl</code>"
@a after using "<code>svn add script.pl</code>".
Use "<code>chmod +x script.pl</code>"
@a before using "<code>git add script.pl</code>"

*/
/** @page styleautotools Autotools Style Guide


+ 19
- 26
doc/openocd.texi View File

@@ -170,38 +170,32 @@ documentation, as well as more conventional bug fixes and enhancements.
The resources in this chapter are available for developers wishing to explore
or expand the OpenOCD source code.

@section OpenOCD Subversion Repository
@section OpenOCD GIT Repository

You can download the current SVN version with an SVN client of your
choice from the following repositories:
During the 0.3.x release cycle, OpenOCD switched from Subversion to
a GIT repository hosted at SourceForge. The repository URL is:

@uref{svn://svn.berlios.de/openocd/trunk}
@uref{git://openocd.git.sourceforge.net/gitroot/openocd/openocd}

or
With standard GIT tools, use @command{git clone} to initialize
a local repository, and @command{git pull} to update it.
There are also gitweb pages letting you browse the repository
with a web browser, or download arbitrary snapshots without
needing a GIT client:

@uref{http://svn.berlios.de/svnroot/repos/openocd/trunk}
@uref{http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd}

Using the SVN command line client, you can use the following command to
fetch the latest version (make sure there is no (non-svn) directory
called "openocd" in the current directory):

svn checkout svn://svn.berlios.de/openocd/trunk openocd

If you prefer GIT based tools, the @command{git-svn} package works too:

git svn clone -s svn://svn.berlios.de/openocd

The ``README'' file contains the instructions for building the project
from the repository.
The @file{README} file contains the instructions for building the project
from the repository or a snapshot.

Developers that want to contribute patches to the OpenOCD system are
@b{strongly} encouraged to base their work off of the most recent trunk
revision. Patches created against older versions may require additional
@b{strongly} encouraged to work against mainline.
Patches created against older versions may require additional
work from their submitter in order to be updated for newer releases.

@section Doxygen Developer Manual

During the development of the 0.2.0 release, the OpenOCD project began
During the 0.2.x release cycle, the OpenOCD project began
providing a Doxygen reference manual. This document contains more
technical information about the software internals, development
processes, and similar documentation:
@@ -210,7 +204,7 @@ processes, and similar documentation:

This document is a work-in-progress, but contributions would be welcome
to fill in the gaps. All of the source files are provided in-tree,
listed in the Doxyfile configuration in the top of the repository trunk.
listed in the Doxyfile configuration in the top of the source tree.

@section OpenOCD Developer Mailing List

@@ -219,10 +213,9 @@ communication between developers:

@uref{https://lists.berlios.de/mailman/listinfo/openocd-development}

All drivers developers are enouraged to also subscribe to the list of
SVN commits to keep pace with the ongoing changes:

@uref{https://lists.berlios.de/mailman/listinfo/openocd-svn}
Discuss and submit patches to this list.
The @file{PATCHES} file contains basic information about how
to prepare patches.


@node JTAG Hardware Dongles


+ 3
- 1
src/openocd.c View File

@@ -255,7 +255,9 @@ int openocd_main(int argc, char *argv[])

print_version();

LOG_OUTPUT("For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS\n");
LOG_OUTPUT("For bug reports, read\n\t"
"http://openocd.berlios.de/doc/doxygen/bugs.html"
"\n");


command_context_mode(cmd_ctx, COMMAND_CONFIG);


+ 11
- 5
testing/index.html View File

@@ -4,10 +4,11 @@

<body>
<h1>Release testing</h1>
A release test must be done on code committed to svn. Commit, then test. That way one can know for sure *what* code was actually tested.
A release test must be done on code committed to git.
Commit, then test. That way one can know for sure *what* code was actually tested.
<p>
Note that this testing document does not have anything to do with testing that is done
before committing to svn. It is a test document for released code. Pre-commit testing
before committing to git. It is a test document for released code. Pre-commit testing
is done mostly by the developer who has written the change. Sometimes code is committed
to synchronize work, even if it has known problems. Release testing is
done on code believed to be stable, often a couple of weeks old, and not by
@@ -17,9 +18,14 @@
All of the above makes it imperative that there can be no doubt about *which* code
is tested and thus all tests refer to committed code by subversion number.
<h1>Release procedure</h1>
OpenOCD trunk is work in progress. Expect it to change daily and to have some quirks.
OpenOCD mainline is work in progress.
Expect it to change daily and to have some quirks.
<p>If you need the latest released and tested version, look for binary snapshots of OpenOCD. Worst case look up the test result table below for the features that are important to you and extract and build the version that has the right cocktail of working features for you. You can also work with the community to address the problems you are seing. Testing work and bug reports are highly appreciated.</p>
<p>The OpenOCD community may decide to create release branches. If this happens, then a branch will be created from OpenOCD trunk. The particular version to create that branch might be an older version rather than the latest and greatest. Fixes are then ported to that release branch from OpenOCD trunk.</p>
<p>The OpenOCD community may decide to create release branches. If
this happens, then a branch will be created from OpenOCD mainline.
The particular version to create that branch might be an older version
rather than the latest and greatest. Fixes are then ported to that
release branch from OpenOCD mainline.</p>
<hr>
<h2>OpenOCD smoketests</h2>
This is a set of tests that exercise the entire OpenOCD system and various targets. It
@@ -34,4 +40,4 @@
<a href="testcases.html">Test cases</a>
</body>

</html>
</html>

+ 16
- 5
testing/smoketests.html View File

@@ -4,7 +4,8 @@

<body>
<h1>OpenOCD smoketest results</h1>
These tests can be performed on any JTAG device as long as they are executed using the unmodified code from SVN.
These tests can be performed on any JTAG device as long as they are
executed using the unmodified code from git.
<p>The latest version in which the test is known to have passed is in the table below.</p>
<h2>Vocabulary</h2>
<table border="1">
@@ -282,10 +283,20 @@
<p></p>
<hr>
<h1>Policy on removing features from OpenOCD</h1>
If a feature in OpenOCD is known to be broken and nobody has submitted a fix and the feature is causing trouble for maintainence, it can be removed from OpenOCD trunk. The threshold for temporarily removing something from OpenOCD trunk is low to ease maintainence and place the burden of maintainence on those that care about a feature.
<p>Note that code is never deleted from OpenOCD svn, it remains in svn so if somebody sees a feature removed that they would like kept, they have but to port and fix that feature back up to main trunk. This document can be helpful in this regard in that the latest working version and the known broken version may be listed.</p>
If a feature in OpenOCD is known to be broken and nobody has submitted
a fix and the feature is causing trouble for maintainence, it can be
removed from OpenOCD mainline. The threshold for temporarily removing
something from OpenOCD mainline is low to ease maintainence and place the burden of maintainence on those that care about a feature.
<p>Note that code is never deleted from OpenOCD git, it remains in the
repository so if somebody sees a feature removed that they would like
kept, they have but to port and fix that feature back up to main
mainline. This document can be helpful in this regard in that the latest working version and the known broken version may be listed.</p>
<h1>Policy on adding features from OpenOCD</h1>
To add a feature to OpenOCD, generally it should not break any existing features and it should be functional and the code reasonably readable and useful to others in the OpenOCD community. The code does not have to be completed. Work in progress is fine for OpenOCD trunk.
To add a feature to OpenOCD, generally it should not break any
existing features and it should be functional and the code reasonably
readable and useful to others in the OpenOCD community. The code does
not have to be completed. Work in progress is fine for OpenOCD
mainline.
<p>Also new tests should be defined. Note that the code does not have to pass all the tests. In fact it can be helpful to have tests to describe facets that really should be working, but aren't done yet. </p>
<hr>
<h1>ocd4 - ARM7 debugging<a name="test_ocd4"></a></h1>
@@ -320,4 +331,4 @@
<p></p>
</body>

</html>
</html>

Loading…
Cancel
Save