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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
