BSP maintenance (was Re: set_vector() on SPARC)
Chris Johns
chrisj at rtems.org
Wed Oct 21 21:57:49 UTC 2020
On 21/10/20 4:46 pm, Sebastian Huber wrote:
> 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
This may be what we want, I have not looked into in detail. I am currently
interested in how we evaluate what we have and how I should view patches for
BSPs and BSP interfaces. The details on managing the outcome maybe something
like Linux but I would like to understand the problem we are solving first. I am
sure if you and I separately took the Linux process and applied it we would end
up with different results.
>
> I consider the bfin and sh targets for example as clearly unmaintained.
>
I think we agree but I am not sure it is for the same reasons.
Please note, I am not asking you or anyone to sit down and write these
guidelines before anything further can happen. I would like to get a place
holder for something and maybe an outline of what we think it should contain.
Chris
More information about the devel
mailing list