* Leverage existing systems to manage patches, bugs, and features.
- Right now, this seems to just be handled in the mailing list.
This seems like a rather risky method to maintain important features and
bugs. OpenOCD already has a site up on BerliOS
<http://developer.berlios.de/projects/openocd/> that has patches, bugs,
and feature databases that OpenOCD can use to keep an eye on existing items.
- I might suggest a look at Trac <http://trac.edgewall.org/> as a
possible new project management tool. It has great support for bug
management and includes a wiki for any quick documentation needs.
* Utilize continuous integration systems like Hudson, Conitnuum
<http://continuum.apache.org/>or CruiseControl
<http://cruisecontrol.sourceforge.net/>
- One of the things I have noticed is that a continuous integration
system really helps to make sure that different commits do not hurt the
mainline. In fact, this can be leveraged to test the build on various
systems if individuals are willing to run a continuous integration
systems on the different platforms. Perhaps a VM?
* Use branches for core changes that break other things to avoid
slowing development of other features.
* Start putting together actual milestones and goals for release dates
so OpenOCD can have an actual release cycle.
- I've been working on becoming a Fedora packager so I can package
OpenOCD for Fedora, but I'm not sure how it will work if the head isn't
stabilized and a release is agreed upon by the community every so
often. I don't think arbitrary releases from head is a good idea.
Zach Welch wrote:
Hi all,
I hereby solicit opinions for how the OpenOCD community should be run.
Please reply with your list of policy and process ideas in this thread
(in bullet list form, preferably). Brevity and clarity will make it
easy for your suggestions to be incorporated into any first drafts.
Please do _not_ reply to others' replies to this thread. If you have
more ideas to add later, reply to your _own_ post and do _not_ address
other posters ideas directly. Copy and paste the ideas you like into
your own original post if you feel the need to "me too"; I want
everyone's individual opinions to be as clear as possible.
To wit, I do not want this thread to turn into a debate. That will only
impede the consensus process at this time. Instead, this should be a
freestyle session of brainstorming that precedes any actual debate.
No one is wrong; everyone is right. Let us assign those labels later.
With a public record of the way everyone thinks things should be done,
any one of us can draft a set of policies that represent the majority.
One or more drafts can be presented, the best ideas selected and honed,
and then the community can vote to accept the final document (or not).
I believe this should help us move forward from here, but you are free
to use this thread to present your opinion as to why this won't work. :)
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
