New validation test suites

Tue Feb 15 08:48:31 UTC 2022

On 15/02/2022 02:16, Chris Johns wrote:
> On 15/2/22 12:43 am, Sebastian Huber wrote:
>> On 03/02/2022 09:09, Sebastian Huber wrote:
>>> On 30/01/2022 23:26, Chris Johns wrote:
>>>>>>> We just have to create a
>>>>>>> release branch for RTEMS 6 and reference release branch commits in the
>>>>>>> submodules.
>>>>>> How do you validate the generated sources in the sub-modules match those in
>>>>>> the
>>>>>> branched submodules? I think this should be done as part of the release
>>>>>> procedure to catch any mistakes.
>>>>> I will write something about this in the release procedure documentation.
>>>> Thank you, I appreciate this. This is a big help.
>>>
>>> I added a note to the post-branch procedure:
>>>
>>> https://docs.rtems.org/branches/master/eng/release-process.html#post-branch-procedure
>>
> 
> Thank you.
> 
> I noticed the documenting of branches in the procedure. Is it required they be
> present to run the procedure? An important phase of making a release is the
> release candidates and these are run off master. Branching before we know we are
> close to working is an important aspect of the pre-release testing as it brings
> a range of parts together. This should happen before branching.

At the moment there is a gap between the RTEMS sources used by 
rtems-central.git and the RTEMS sources in rtems.git. The goal is to 
close this gap so that rtems-central.git can point to a commit in 
rtems.git. However, this is a process which may need a couple of months. 
On the master branches this gap is not really an issue. On a release 
branch it would be an issue and this is covered by the post-branch 
procedure in the manual now.

> 
>> How do we want to proceed here?
> 
> I am currently rather busy on something and will be for a while. As a result I
> have been a little distracted and I apologise for this.
> 
>> I have no idea what should I do next.
> 
> As has been stated, making a release takes some time and effort and my
> experience of doing it has taught me all the detail needs to be covered. Until I
> can see rtems-central integrated into a release we cannot not depend on it.
> Given the way the validation tests have been created merging makes rtems.git
> depend on rtems-central if merged. In the past we have not taken care of these
> things and it has fallen to me to sort out and I prefer that does not happen in
> this case.

 From my point of view, the release related activities for 
rtems-central.git are covered in the Software Release Management chapter.

> I should also state the rtems-central repo is on probation and even if it is
> added to a release it will still remain like that for a reasonable period of
> time. It is still not clear where the line of responsibility lies with that repo
> and the long term maintenance of the qual effort. This may appear abrupt however
> I need to be clear about this so there is no misunderstanding.

My ability to predict the future is also rather limited. I focus 
currently on the integration of the remaining work done for the 
pre-qualification activity. This is enough work to keep me busy for a while.

> 
>> The new validation tests are not the only work from the pre-qualification
>> activity I would like to integrate. We also have work from Andrew Butterfields
>> related to formal methods. There are changes in the GR712RC and GR740 BSPs, the
>> gcov code coverage support, and build system changes to support the build of
>> RTEMS libraries which contain only the pre-qualified feature set.
> 
> Making a release is documented here:
> 
> https://git.rtems.org/rtems-release/tree/README.txt
> 
> I run a single command that creates a complete release. How will the procedure
> outlined in the eng manual be implemented here? [1]
> 
> What will an rtems-central tarball look like? I am specifically concerned the
> export process to turn a git repo into a tarball will include a copy of the
> sub-modules. This is the current way the release scripts work. If this is the
> case we will have 2 copies of some repos in the release and I think that is a
> bad idea.

We don't need a rtems-central tarball for releases. This repository 
contains nothing directly relevant to an RTEMS user. In theory the 
rtems-central.git repository could be used to make releases. It could 
make sense to move the stuff in rtems-release.git to rtems-central.git.

> 
> Chris
> 
> [1] The release scripts assume an autoconf RTEMS and so I suspect what is there
> is broken. This makes the rtems-central integration more complicated than it
> need be. I have not looked at what is needed

I updated the scripts so that they support the new RTEMS build system. I 
fixed also some FreeBSD/GNU compatibility issues. It still doesn't run 
completely on Linux. One issue is the missing "sha512" command line tool.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/