On 21/10/2020 04:06, Chris Johns wrote:
Those who are not in constant testing... well they are not tier 1, right?
Yes but how does that fit in with idea of "being maintained" or "not being
maintained" and under what terms do we accept changes to BSPs and the interfaces
they use?
I suppose I am after some guidelines to help us manage expectations. We have the
expectations of developers making changes and those reviewing patches and we
have our users. Do we explained to our users that keeping RTEMS current and
modern means we may break BSPs and drivers? Do we explain we are in dark with
BSPs we do not see hardware test results for? I d not think we do. I am
wondering if doing so may feedback into how we maintain BSPs. Would we be more
aggressive with changes if we know a lack of test results for a BSP a user is
vested in may require extra support overheads to make work again?
I am attempting to see if can move from this being subjective to it reflecting
what we have. I would also like have it clearly understood by our users that
testing on hardware is the only means we have to know things work.
I suggested a while ago to add a section to the MAINTAINERS file which
covers the maintenance state of RTEMS components. Something similar to
what Linux has:
https://github.com/torvalds/linux/blob/master/MAINTAINERS#L80
I consider the bfin and sh targets for example as clearly unmaintained.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
