On 3/5/17 4:28 pm, Sebastian Huber wrote: > On 03/05/17 08:17, Chris Johns wrote: >> On 3/5/17 3:40 pm, Sebastian Huber wrote: >>> On 03/05/17 07:28, Chris Johns wrote: >>>> On 3/5/17 3:09 pm, Sebastian Huber wrote: >>>>> On 02/05/17 23:30, Chris Johns wrote: >>>>>> On 2/5/17 6:20 pm, Sebastian Huber wrote: >>>>>> [...] >>>>>> If you want to add this test please extract the version details from >>>>>> the >>>>>> build system >>>>> Can we trust the build system? >>>>> >>>> Given the header file with the values it created by the build system >>>> yes >>>> we can. >>> I don't think we can trust the build system. The requirement for a >>> release is that the version macros should have specific values. We >>> should test that this is the case. >> We have to trust the build system for a clean or fresh build and if we >> cannot not it is a bug. To state otherwise expands the scope of >> uncertainty and I do not believe we need too. >> >> I will state again, doing this breaks the release process. I am sorry >> but this is just now the release model and supporting configuration >> control structures exist. > > I still don't see how this breaks the release process. One task of it is > surly to change the version from N to N + 1. This requires to modify > some files (with a script). This test would be just one of these files. > Some are *.m4 files, some *.c files, it doesn't matter.
It is not that simple. The details are in the rtems-release.git repo. There are a number of ways this can be done, I have settled on this release model and I do not wish to revisit it. It has been like this for while now and given I am the only one doing any of this it is reasonable to have the major say. All efforts have been unfunded. A release is defined as the compressed tar file and the release signature is the SHA512 hash. A release defined this way is unique and this is important. You cannot clone it, you can only clone an equivalent and that equivalent will have the branch's version numbering not the release's version numbers, again this is important. The cloned version and the real release are not able to be mixed without direct intervention by someone and that invalidates the configuration. The release's tar file contains file system's meta data which effects the SHA512 hash and that makes replication difficult. The version.m4 file are modified during the release process to the release specific details and the build system files are generated. This is understood and accepted and that part of the release can be separately audited and checked. The RSB, docs and rtems-tools have a different method where a VERSION file is added to the archived cloned repo files. The release branch version tested is the version released and tagged. It does not contain extra commits to fiddle embedded version numbers such as this test. There is also no need to perform any post release commits on a release branch to put back the release branch version numbers which is needed to make the repo meet the release branch requirements for the next dot release. I wanted to avoid this type of repo noise and the complexity created if any of the commits needed fail requiring recovery processes. Any time manual actions are needed auditing demands increase. It is not enough to have requirements, you need to prove it happened. I do not want the release process touching .c, .h etc type files. I am touching the version.m4 files because I have too. I would prefer to add a file. The release process runs without intervention from the start to the end across a number of repos and packages. Once created a separate process runs to tag the repos and the release hash. I hope this helps explain what is happening. > >> >>> Maybe we have some time in the future something like this: >>> >>> Requirement 2341: There shall be a C pre-processor define >>> __RTEMS_MAJOR__ available via #include <rtems.h> defined to 123. >> I doubt this would be in the RTEMS Project's requirements. It might be >> in a qualification package for the specific qualification effort. > > It is a RTEMS Project's requirement. Its just not explicitly stated. If > you release RTEMS 3.4.531 a user expects to have > > #define __RTEMS_MAJOR__ 3 > #define __RTEMS_MINOR__ 4 > #define __RTEMS_REVISION__ 531 > Yes but the requirement does not state exact version numbers, rather it would define the release number fields, what they mean, how and why they change, and how they can be used in software via the defines. >> How >> that define it created is for the RTEMS Project to determine. > > Yes, but somehow the define must exist with the right value and this is > what needs to be tested. > Is this a cat in a box type issue? I am happy for a test to check the macros are suitably formed and meet the needs of the compiler, language etc. I feel any specific version check is something a user needs to wrap around RTEMS once installed. They could grep, sed and check the values because the test confirms they are correctly formed. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
