4.11 Release Requirements Branching
gedare at rtems.org
Mon Jan 13 14:15:20 UTC 2014
On Mon, Jan 13, 2014 at 7:48 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Hello Joel,
> some notes regarding your list:
> The following are things that MUST be resolved before 4.11 is branched:
> Tools stabilized on known versions
> Looks impossible to have all tools on same GCC version.
> Some GDB simulators do not support Mingw. We will likely have to
> accept that.
> -> Yes, some targets seem to lack proper upstream support.
> All BSPs must build without error
> -> Is this with all tests enabled or just the samples?
> Select BSPs must run tests without errors
> List of BSPs and acceptable conditions TBD
> -> Some tests fail due to bugs which will likely be not fixed for RTEMS
I agree with Sebastian, that all tests run without errors may be
impossible for the release point itself, and some of the errors may be
bugs that are not serious.
> Coverage run and baseline for release agreed to
> Need to set coverage goal for either ERC32 or LEON3 and meet it.
> Address Getting Started manual
> RSB not mentioned for one
> All GCI patches reviewed and merged as appropriate
> -> Ok.
> All GSOC projects reviewed and evaluated for merger.
> Minimum is a plan for future
> -> The last parts of atomic operations project (phase-fair read-write lock)
> will be fully merged during the SMP progress, so it should not delay the
> RTEMS 4.11 release.
I would not include any requirements related to GCI or GSOC in our
release procedure, now or in the future.
> Release procedure on git defined
> The following are things that WOULD BE NICE to be resolved before 4.11 is
> Warning reduction pass
> Focus on all SPARC BSPs, select PowerPC, ARM and MIPS
> -> I have no resources for this.
I have no resources. ;)
> All test .doc files in place and updated to not have XX_method RTEID
> form of name.
This seems tangential to a release.
> POSIX and Classic affinity APIs in place
> May not have scheduler with support.
> -> I would should do all further SMP related changes in the next RTEMS
> OS Web Monitor in network demos
> Pok and i386 hyopervisor patches
> -> No opinion here.
network-demos is separate repo so not an issue.
I don't think the pok/i386 needs to be resolved for the release. The
paravirtualization effort will likely continue to be an ongoing and
mostly volunteer/GSOC effort for the near future, so we should not
hold up RTEMS on account of it.
> To be discussed:
> Status of USB and new TCP/IP stack
> -> We should not couple the RTEMS 4.11 release with the network stack
I agree. I think if the current and new stacks are not quite working
right, 4.11 users can be guided to another solution like LWIP.
> -> We should add the next RTEMS version number to the Bugzilla (e.g. 5.0)
> and move the milestone for all open bugs or fix them.
> Sebastian Huber, embedded brains GmbH
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.huber at embedded-brains.de
> PGP : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> rtems-users mailing list
> rtems-users at rtems.org
More information about the users