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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
