cynt6007 at vandals.uidaho.edu
Mon Jul 15 17:37:09 UTC 2013
I agree we should get the release process going...
I propose the release criteria include:
1. All tests compile and link for all BSPs
2. The hello, world and ticker demo run for all simulated BSPs that support the rtems kernel
3. We have some sort of linking and running criteria for rtems toolchains without rtems kernels, or we don't have rtems toolchains for rtems kernels
4. All features documented in the release notes are tested (where feasible) on simulated BSPs, and compile / link for non-simulated BSPs
5. All features that ran on rtems version 4.10.2 either also run on the next release of rtems, or the feature's removal is documented in the release notes.
6. (Process) we have a build-bot script running that checks (and rejects) each rtems patch for compile / link errors (that checks every BSP)
7. (Process) we have a script that builds and tests the trunk of binutils, gcc, newlib, gdb which in turn builds all the rtems tests (referenced against the rtems trunk revision as of the time of the gcc release) and posts the results to gcc-testresults (as binutils, newlib, and gdb don't have a test results email).
8. I also would like to see included in the release documented recommended configurations for binutils, gcc, newlib, gdb, and the rtems kernel (for each supported host and each supported target).
I suspect tackling 6+7 first will reduce BSP breakage in the future, and help with 1-5...
From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Gedare Bloom [gedare at rtems.org]
Sent: Friday, July 12, 2013 10:22 AM
To: RTEMS Devel
I propose we get the next RTEMS release going. Anyone has objections?
This release process will be re-defining the release processes for the
future also, since there have been some changes made from both
technical and management view points.
rtems-devel mailing list
rtems-devel at rtems.org
More information about the devel