On Dec 2, 2008, at 11:30 PM, Øyvind Harboe wrote:
On Wed, Dec 3, 2008 at 8:10 AM, Rick Altherr <[EMAIL PROTECTED]> wrote:Please feel free to provide commentary on any and all portions of this. I've written it in the format I expect to use for future status updates.Summary -------------The majority of the development work for 1.0 GM has already been committedto trunk but has yet to be integrated into the RELENG_1 branch. Manynon-development tasks need to be performed after 1.0 GM has been declared before FCS can occur. The bulk of that work is related to building a list of officially supported host OSes and devices. The tentative schedule is todeclare GMc by 12/14/2008, GM by 1/1/2009, and FCS by 2/1/2009.Let's do GMc no sooner than jan 1. 2009
I wrote it originally with GMc 1/1/2009, but 1 month seemed like a long time given that all of the major code contributions are already done.
Terminology -----------------In the course of planning for the OpenOCD 1.0 release, I will be using a number of terms commonly used in software program management. I'm includinga quick reference for some of these terms for those unfamiliar.Wikipedia reference?
I didn't use one. This is drawn from personal experience with a number of software companies.
GM - Gold MasterThe complete source base that the released source and binary distributionswill be built from. This will be tagged in Subversion as part of therelease process so the exact sources used for the release can be retrievedshould they be necessary. GMc - Gold Master Candidate Once all of the source and documentation tasks are complete, a sourcedistribution will be built with the intention of being the release version. Final testing in performed on this distribution and if no issues are found,it becomes the GM. FCS - First Customer ShipAfter the GM has been declared, tagged out in Subversion, and the source distribution has been created, there will be a period of time before all of the binary distributions are ready. When the supported binary distributions are ready, the source and binary distributions will be posted to the OpenOCDproject page. The posting is considered FCS. Supported device Any device which OpenOCD can identify and interact with. Officially supported deviceAny supported device that has passed the defined test criteria when usingthe GM sources on an officially supported host OS.I think we should refrain from endorsing hardware or saying that somethingis "officially supported". It either passed the test for a specific release or it didn't. Officially supported implies something about the future.
Not really. The intent is define a set of host OSes and devices that are known to work with a specific release. If we want to call it something other than "officially supported", that's fine, but we should come up with a term.
The OpenOCD policy is that all hardware is equal. The only thing that distinguishes it is testing and patches contributed
Sure, so anything that OpenOCD knows how to talk to is considered supported, but that doesn't eliminate the need for knowing which devices have been tested against a given release.
Supported host OSAny OS on which OpenOCD has previously been verified to compile and executefor general usage. Officially supported host OSAny supported host OS that has passed the defined test criteria when usingthe GM sources against an officially supported device.Change "supported" by "passes tests in this release".Overview of tasks for 1.0 GM ----------------------------------- - Code changes - Remove deprecated/obsolete syntaxes - Add support for JTAG route controllers - Reorganize and update documentation - Officially supported device/OS testing- Define criteria for officially supported devices (what tests must pass onGMc)see openocd/testing directory for a start.- Obtain test devices for all supported interfaces, targets, plds, andboardsThe community must do these tests. This hardware will *never* be assembled in the same physical location.
Correct. So, we should try to build a list of people who are willing to do testing and what devices and host OSes they are willing to test on. That way we know that when a GMc is ready, we have at least a subset of devices available for testing.
Test results can be submitted *after* the FCS.
Certainly, but it is best to have the testing done before FCS if possible. That way any device-specific or OS specific bugs can be encountered and resolved or documented for the release.
- Draft test matrix of supported host OSes and devices including contributors capable of testing configurations - Verify all supported devices meet test criteria - Binary releases Code changes ---------------------All of the major code changes to be included in the 1.0 GM have already been committed to trunk, but have yet to be integrated into the RELENG_1 branch.The new JTAG route controller support was an extensive change that touched many areas of the source base. Preliminary testing has already been done, but further testing needs to be done on various host OSes and devices beforethe changes can be considered stable and ready for integration into RELENG_1.The removal of obsolete and deprecated syntaxes is a relatively small set ofchanges and has minimal risk. These changes will be integrated into RELENG_1 in the new week. Documentation changes ----------------------------------While the first batch of documentation changes have been committed to trunk,the newly restructure document needs to be proofread and checked foraccuracy. Once the remaining author's notes and outstanding feedback havebeen addressed, it will be ready for a merge into RELENG_1. Officially supported device/OS testing --------------------------------------------------To ensure that users, both new and old, can easily determine whether OpenOCD"whether a version of OpenOCD will work with".... there is no guarantee about the future.
Yes, the results of testing will be specific to a host OS, host architecture, OpenOCD version, dongle, and target device.
will work with the host OS and devices they wish to use, a list ofofficially supported host OSes and devices needs to be developed to coincide with the 1.0 FCS. Officially supported host OSes and devices are determined by defining a set of test criteria and then evaluating a host OS or device against those criteria. Only host OSes and devices that passed the test criteria when using the GM source distribution can be considered officially supported. The resulting list of officially supported host OSes and deviceswill be published as part of the FCS process. Binary releases ---------------------After GM, a set of binary releases need to be created for common host OSes. The releases should use the host OS package format and be tested againstthe criteria for an officially supported host OS. Schedule ------------- GMc 12/14/2008 GM 1/1/2009 FCS 2/1/2009 Being the first release of OpenOCD, it is vital that quality isexceptionally high and the new user experience is thought out. That said, this is a fairly aggressive schedule and as such is at risk should any majorproblems be encountered during testing.As a general comment I'd like to see the release process a bit more open source oriented. Also, most of the contributions are from amateurs(testing and development), so we have little control over how and when things are done.
The traditional open source way is to pick a source revision, mark it with a new version number, and put it on a website. While that works, it leads to lots of pain and suffering for users. Not only are releases rarely tested, but it isn't entirely clear what was changed or that the changes were actually stable.
The goal in any release coordination, open source or commercial, is to set expectations. If tentative dates are not set, you end up with the FreeBSD 5 fiasco. I entirely expect contributors to pitch in as they can and the actual dates to change. But by setting expectations and goals, the set of items to be included in OpenOCD 1.0 is well defined and the criteria for its release is also well defined. Setting target dates for major milestones simply provides some guidance and incentive to get fixes in now rather than waiting. If those dates arrive and things are in a bad state of affairs, the dates will get changed.
OpenOCD is free as in free speech, so we do not "support" anything.
There are multiple levels of "support." OpenOCD, software or community, does not offer contractual support, paid support, or any other form of dedicated support. The OpenOCD community does however know which devices work, which OSes work, what versions are best to use, etc. Putting that on a webpage or wiki is a form of support even if it does not constitute a contractual obligation.
There are only patches being submitted and accepted and test results recorded. That can yield a working version of OpenOCD of a combination of OS+hardware or not.
I in no way intend to state or imply that the OpenOCD community will ensure that a certain set of devices will _always_ work for every release. Rather, I would like to see each release have a corresponding list of tested configurations that are known to work. I would also like to have contributors willing to do that testing when a release hits GMc.
-- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer
-- Rick Altherr [EMAIL PROTECTED]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
