The EMC team uses SourceForge Trackers to keep track of bug reports and feature requests, and to help guide development effort. This page has links to the trackers, and explains how they are used by EMC. |
To see the list of existing bug reports, click [here].
The most useful bug reports (and the ones most likely to get quick results), are ones that describe in as much detail as possible what happens, and under what conditions. You should include information about your system, what RTOS you are using, etc. Describe the conditions that lead to the bug, what the program did, and what you think it should have done. Errors in documentation should be reported the same way - describe what the doc says, and what you think it should say. Indicate whether it is simply unclear, or if it doesn't match the actual behavior of the program.
If possible, you should register with SourceForge and log in before submitting a bug report. That will allow us to keep you informed about the progress of your report, or contact you for more information. To register, click [here]. If it is impossible or impractical for you to register, you can still submit a bug report. However anonymous reports are harder for us to act on and may get a lower priority.
If you are unfamiliar with reporting bugs, here is a useful [Guide for effective bug reports] - this really helps developers to reproduce and isolate a problem.
To submit a bug report, click [here].
To see the list of existing requests, click [here].
The Enhanced Machine Controller design process is open to ensure a system that reflects the needs of the user community. Listening to the needs of users and developers ensures that valuable suggestions for improvement can flow into project. As you consider submitting a feature request, toss it about a bit with others on the EMC lists so that your request comes to the Board ready for them to set priority and assign people.
You must register with SourceForge and log in before submitting a feature request. That will allow us to keep you informed about the progress of your request, and contact you if we need more information. To register, click [here].
To submit a feature request, click [here].
Priorities are assigned to each tracker item by the EMC board of directors. The priority of an item indicates how important it is to the overall project, and each developer should ideally work on the highest priority item that they feel capable of handling. (Although there is nothing wrong with fixing some low priority items if you don't have the time or energy to tackle something big.)
:Urgent safety critical issues - All developers should concentrate on fixing level 9 reports as quickly as possible.
:Fatal bugs - those that completely prevent EMC from operating. Build failures, crashes, kernel oopses, segfaults, and the like.
:High priority bugs - those prevent EMC from operating correctly.
:High priority feature requests that would greatly enhance EMC.
:Medium priority bugs - those that affect only certain G-code programs, or certain drivers, or some other small subset of the user base.
:Medium priority feature requests that are either critical to a small subset of the user base, or widely useful but non-critical.
:Low priority bugs - those with known workarounds, but which should still be fixed properly.
:Low priority feature requests that are only minor improvements, or which benefit a very small number of users.
:Nuisance level bugs and minor improvements that can be done as time and manpower permits.
:Cleanup issues like misspelled error messages or prompts, coding style violations, minor documentation revisions.
:Feature requests that will have no real effect on how the program actually works, but will make the code or documentation more readable, or have other benefits.
:Features that would be nice, but aren't currently practical for various reasons. (Or bugs that simply can't be fixed without work that is out of proportion to the benefits gained.) They are good things to think about, and if you have ideas toward implementing/fixing them, feel free to post comments to the tracker item. In some cases, a level 2 item will result in other items being submitted, as steps needed to make the original item possible. When it becomes practical, the priority will be raised.
:Newly submitted items to which the board has not yet assigned a priority
Trackers use categories to group related items together. Tracker items can be sorted by category to allow developers to quickly find items they can work on. When submitting an item, pick the catagory that you think best fits it. If you're not sure, just leave the catagory as "none", and the board will assign a category.
The following list is a combination of the existing categories and some proposals. (Currently there is only one category for all EMC1 items.) This list is subject to change.
EMC1 related categories
*G-Code Interpreter & Task Controller
*Motion Controller & Device Drivers
EMC2 related catagories
See the Issue Tracker link at http://linuxcnc.org/community/|