Hi all,
I would like to define a modest feature set with a list of use-cases.
Here would be my various criteria, were I to implement one from scratch:
General Requirements:
- KISS: simple to use, simple to change, simple to love.
- allow anyone to report issues; do not _require_ creating an account
- designed to manage data orthogonally (e.g. wikis, databases, etc.)
- easy to maintain (install, setup, back-up, redeploy, restore, etc.)
- easy to customize (we need to add boards, targets, interfaces, etc.)
Command-Line Support:
- ability to file one-step bug reports ('make smoketest')
- ability to share patches/files quickly and easily ('make postpatch')
- ability for developers to retrieve patches easily ('make fetchpatch')
- ability to script interactions with the remote application server
- allow us to write custom tools, such as to...
- post a series of patches (or group of bugs) and then "link" them
Web Interface Support:
- NEVER _require_ developers to use the web interface rather than ML.
- can publish all data and files on the web via readable permalinks
- patches should be colorized and inline (and also as attachments)
- files download with the same as the poster gave it! *peeve*
- on-line forms for users to submit/view bug reports with releases
- produce standard/custom project reports and graphs.
Mailing List and E-mail Gateway Support:
- from list to system:
- detect "properly formatted" patches/reports automatically.
- accept patches that pass review for style and clear unit tests
- accept random/reworked issues forwarded for entry in the system.
- from system to list:
- send notices about additions or changes made to the system...
- ...except those made by the incoming gateway processes...
- ...well, maybe an 'added as issue #' confirmation for those...
- ...or a systematic (i.e. objective) list of reasons for rejection
- send comprehensive periodic reports with yummy statistics
- from e-mail to system:
- allow "properly formatted" replies to be detected and entered
- accept patches that pass review for style and clear unit tests
- allow other commands (e.g. majordomo, mailman, etc.), such as:
- request standard/custom reports be generated in reply
- from system to e-mail:
- send confirmation of submissions made via any of the above means
- send updates to watchers when changes are made to an issue
- send reminder e-mails for inactive issues
- send out text or HTML of standard/custom reports
Basically, I want a double-trifecta: CLI, Web, and E-mail interfaces for
Bugs, Patches, and Content Tracking. I want to use each interface to
the best of its advantage for the task at hand; by using patches alone,
I listed enough use-cases for each UI to put a sharp tip on this point.
Given my specification, no system does this as well as it could, based
on my past experience with numerous tracking systems.
Do any solutions out there meet these requirements today? Or, is this
complete set of features desired by others than myself? If not, do
these features seem like too much to ask? If not, what should be the
priorities? Or, what constructive advice would you give someone that is
developing such a system and would customize it just for OpenOCD?
I hope that that this analysis shows thorough consideration. Certainly,
I have expectations that may be difficult to resolve, but settling for
anything less would be a disappointment. Instead, I would like to see
if the community can reach some consensus on features before we continue
chasing Quixotic dragons. We need to solve the actual problems at hand.
On _that_ note, we might back up yet further to clarify exactly which
problems we want to solve in the first place.... *sigh* Before we can
say The Answer is 42, someone need remind me: what was The Question? ;)
"We need bug, patch, and testing tracking" did not produce this post.
No, I want tools that will make our development _faster_ and _easier_.
However, correlation does not imply causation: adding new tools does not
always produce these intended effects. However, I know that we can find
suitable choices, after a deliberate search and due diligence.
Meanwhile, I hope the community will be constructively patient during
these forthcoming discovery, exploration, and transition process. While
I have my own proposal to address this already written up, I would like
to give the community some time to consider and respond to these points.
Sincerely,
Zach Welch
Corvallis, OR
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
