4.11 Release Requirements Branching

[Gedare Bloom]

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
> 4.11.
>
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
> branched:
>
>     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
> release.
>
I agree.

>     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
> progress.
>
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
> http://www.rtems.org/mailman/listinfo/rtems-users