4.11 Release Requirements Branching

[Chris Johns]

On 14/01/2014 10:18 am, Nick Withers wrote:
> On Mon, 2014-01-13 at 16:35 +0100, Ralf Corsepius wrote:
>> On 01/13/2014 01:48 PM, Sebastian Huber 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
>> Primary issue to me: Newlib's lack of API/ABI stability.
>>
>> To many changes. That said, I do not see any perspective for an RTEMS
>> release unless there are, say at least 2 months without newlib receiving
>> RTEMS-related changes.
>>
>> In case somebody wonders, why I haven't upgraded newlib in my toolchain
>> packages: The churn the RTEMS submissions are causing have become
>> unprocessible to me.
>>
>>>           Looks impossible to have all tools on same GCC version.
>> Correct.
>>
>> IMO, it's time to pull the plug out of some targets.
>
> Since it's (sort of) come up...
>
> Personally, I really like FreeBSD's concept of "Tier 1" et al.
> architectures
> ( http://www.freebsd.org/doc/en/articles/committers-guide/archs.html ).
>
> So a Tier 1 RTEMS BSP would build all tests, have active maintenance (at
> least for the architecture), have remote GDB support, all board devices
> supported (or those not supported explicitly stated, at least) and other
> documented attributes.

I like this idea however I am not sure about the details. I think we can 
add tiers for architectures and make that work. The architecture needs a 
BSP or BSPs that can be tested and and meets the test profile. Tests 
that fail need to be fixed. We can decide what that profile looks like 
on a BSP by BSP basis. I suspect this will most likely be based on open 
source simulators because they are available.

The issue with specific BSPs is the project's access to specific 
hardware. The RTEMS project cannot purchase all the hardware supported 
by RTEMS. If a user wants a specific piece of hardware to be in tier 1 
they may have to donate that to the project or supply regular test 
results. Again I am not sure how this would work.

>
> Perhaps then some of the less supported architectures could be kept but
> it'd be nice and clear to potential users looking for a platform that
> these aren't the go - or require a significant investment of time into
> fixing up.
>

I tend to think we follow the upstream of gcc in this case.

Chris

> Just a two cents thing :-)
>
>> Esp.:
>>
>> - the avr, lm32 and m32c target should be discontinued, because the
>> corresponding toolchains are in rather unusable shape with no
>> improvements in sight.
>>
>> - the sh and h8x also seem to be candidates for discontinuation.
>> At least I don't see a viable userbase of them.
>>
>>>           Some GDB simulators do not support Mingw. We will likely have
>>> to accept that.
>> Correct.
>>
>>
>>>       Status of USB and new TCP/IP stack
>>>
>>> -> We should not couple the RTEMS 4.11 release with the network stack
>>> progress.
>> My opinion: Not ready, postpone after 4.11.
>>
>> Ralf
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>