Release?

[Rempel, Cynthia]

>On Mon, Jul 15, 2013 at 1:37 PM, Rempel, Cynthia
><cynt6007 at vandals.uidaho.edu> wrote:
>> Hi,
>>
>> 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
>Can you explain this #3? I don't quite get it.
Users use toolchains built with (i.e. xxx-rtems4.11-gcc), but they don't use the rtems kernel for their "bare metal" embedded work... don't know why... but if we support users of these toolchains we should test the toolchains...

>> 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).
>These #6 and 7 will have to wait, but they are not specificaly
>release-related. At the least, 6 won't be feasible until after we
>release 4.11.
That sucks that we're stuck manually checking each patch...

FWIW, there will most likely be pressure to add features up until the release... in which case, what will probably happen is a "feature freeze" -- which will be unpopular and lead to "coding opportunity loss" -- and we'll be putting out a release that doesn't compile/link on some targets...

Although at one point I was able to build the toolsets using the RSB (before it built the kernel) on gcc-20, and it successfully found the targets with the errors, it might be as simple as to take such a script and use the number of lines of compiler errors to determine if there is a problem with the patch...  (It could be a git script)

(Of course, we could avoid this problem by using a script to:
a. build rtems on all targets -- RSB is very useful for this, 
b. put the output into a file,
c. filter the output file for compiler and linker errors into another file
d. if the number of lines in the filtered file exceeds a specified number -- reject the patch)
This of couse won't catch all the errors, but likely many of them...

But if hooking such a script into git isn't feasible, it's not... that sucks.
>> 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).
>>
>When you say configurations, do you refer to how the packages are
>built? E.g. for autotools packages, the command line options to
>"configure"?
Yes, this is pretty simple to do... (basically take the configurations from the RSB)...
There will be deviations possible, but a set of supported configurations would make it easier to identify what needs tested before we put it out...

>> I suspect tackling 6+7 first will reduce BSP breakage in the future, and help with 1-5...
Hopefully we can agree on what needs to happen before the release... (perhaps 1, 2, 4, 5, 8 and additional criteria as specified from input in the community).