Suggestions for BSPs to Obsolete

[Joel Sherrill]

On 10/21/2015 12:41 AM, Thomas Dörfler wrote:
> I have discussed dropping BSPs from support and from a technical point I
> fully agree that this must be done. We should have some sort of active
> BSPs which are regularily tested.
>
> On the other hand, RTEMS can only live and grow, if it is attrative
> enough for new users. Therefore we should not simply drop old BSP and
> remove them from mentioning. Instead we should keep a list stating
> "mr332 supported up to version 4.9". This indicates, that the basic code
> is still available for taming the processor, but the structure and API
> may need tinkering before working again with 4.12.

The Wiki pages for BSPs have included this information when we have
done this in the past.

One of the things I stated was that nothing would be removed before
instructions for removing a BSP and architecture were in the Wiki.
This is specifically to provide a checklist, encourage removing
the BSP as a single commit, remember to touch documentation, wiki,
supported CPU lists, update a BSP Wiki page, etc.
  
> This is not so important for the really old BSPs (68k-based, various
> other stuff), but also for those, which just pop into RTEMS but then are
> not properly maintained (like possibly some STM/ARM stuff).

IMO this sweep is more for the long dead and to reduce the number of
configurations to convert to waf and to feed into Buildbot.

Beyond that we need tiers. This morning on the way in, I thought it
would be good to get a notice out to the EPICS community to get a
list of boards they actually have an interest in. We normally don't
hear directly from them. Chris and I discussed the mvme136[1] being
removed but the mvme147, 162, and 167 have NICs, more RAM, and could
still be used  in the labs. I know I spoke with someone recently
who had 167's as backups.

[1] The mvme136 was the original RTEMS BSP. It was already in use
when I started in 1989. Of the three architectures and BSPs done
during that phase of RTEMS' life. The three were m68k/mvme136,
i386/force386, and i960/cyclone.
  
> wkr,
>
> Thomas.
>
>
>
> Am 21.10.2015 um 01:24 schrieb Chris Johns:
>> On 21/10/2015 12:56 am, Joel Sherrill wrote:
>>> On 10/20/2015 6:15 AM, Sebastian Huber wrote:
>>>> Maybe we should build a list of BSP directories and find maintainers for
>>>> each directory in some time frame. Then remove all BSPs without a
>>>> maintainer.
>>> That is one approach. Another is defining tiers for the BSP
>>> and being more aggressive about dropping them.
>>>
>>> I think Chris has discussed his ideas on tiers before.
>>>
>> I think both will be needed. We are moving to Phabricator and having
>> areas developers can approve will be important. I am concerned if we do
>> not things will sit and not be pushed through.
>>
>> I also think we will need tiers so we can manage the results from
>> buildbot. There are active and current BSPs we have no way of testing
>> because we do not have the hardware. If a user has a board and sets up a
>> slave to allow testing for that BSP it will reach a higher tier and we
>> have better testing.
>>
>> Chris
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985