- Project tools
-
-
- How do I...
-
| Category |
Featured projects |
| scm |
Subversion,
Subclipse,
TortoiseSVN,
RapidSVN
|
| issuetrack |
Scarab |
| requirements |
xmlbasedsrs |
| design |
ArgoUML |
| techcomm |
SubEtha,
eyebrowse,
midgard,
cowiki |
| construction |
antelope,
scons,
frameworx,
build-interceptor,
propel,
phing
|
| testing |
maxq,
aut
|
| deployment |
current |
| process |
ReadySET |
| libraries |
GEF,
Axion,
Style,
SSTree
|
| Over 500 more tools... |
|
|
LinCS
The System Configuration Tool
|
|
|
Contact
You can get in touch at the following email address:
- ame01 AT gmx DOT net
- michel DOT dagenais AT polymtl DOT ca
If you want to signal a bug, please provide the following details:
- Description of the problem - how does it manifests?
- How to reproduce it. If it happens only in a while try
to be as precise as you can.
- Relevant files, entries, values, etc.
- Compiler kind and version
- Distribution, its version, architecture and kernel version
- What is specific to the machine
- Your opinion and suggestions
If you want to send a patch/bug fix: several pieces of information are
needed before to be properly evaluated.
- A description of the bug and how your patch fixes
this bug. A reference to a test suite failure (An opportunity
for contributing a test!) is very helpful. For new features a
description of the feature and your implementation.
- A ChangeLog entry as plaintext (separate from the
patch); see the various ChangeLog files for format and
content. ChangeLogs are also required for documentation (i.e.,
.html/.body/.dot files).
- The patch itself. Use "diff -up OLD NEW"
with GNU diff. If you are going to submit more than
one patch we suggest you check the code out of the
CVS and create your patches via "cvs diff -u".
Send patches as plain text (preferred for the code
itself), MIME attachments (preferred for the web pages), or
as uuencoded gzipped text.
- Please try to run the relevant test suite before and
after committing a patch A contributor might include
before/after test results in their contribution. This
assumes, of course, that there is a test suite for the
feature or patch. Try including tests for any new
features.
- For bug fixes, please try to include a way of
demonstrating that the patch actually fixes something.
The best way of doing this is to ensure that the test
suite contains one or more test cases that fail without
the fix but pass with the fix.
- People are encouraged to submit patches that extend
the test suite.
- Please read your patch before submitting it. A patch
containing several unrelated changes or arbitrary
reformats is hard to make sense of.
|
|
|
|
| |
|