On Thu, Aug 23, 2018 at 9:50 PM, Chris Johns <chr...@rtems.org> wrote: > On 24/08/2018 03:51, Sebastian Huber wrote: >> I would like to propose a procedure for architecture/BSP removal since I >> think the RTEMS master carries to much historic ballast around with no >> active user base. > > For example? We have a history of following gcc. Are you proposing we move > away > from that and if yes why? > > There is tier 5 ... > > https://docs.rtems.org/branches/master/user/hardware/tiers.html > > Tier 5 does not need to build or have working tools. Maybe that should be made > clear in the documentation. > >> Once the release branch is created, an announcement is placed on the devel >> and users mailing lists and the web site news. The announcement should >> encourage all active RTEMS users to test their favourite BSP with the >> release branch and report back the status. Problems should be then be fixed >> with an active involvement of all core developers. > > Why not tag the BSP as tier 5 well before the release? This gives a user of > the > release and the BSP a clear indication of the BSP's status. Anything that is > not > tier 5 is OK and anything that is tier 5 is to be removed unless it can be > moved > to a high tier, ie someone has stepped forward. > >> This announcement is repeated on the mailing lists after two weeks five >> times. This gives a testing period of three months. This should be enough to >> cover holiday seasons and urgent project schedules. Users may request an >> extension of the period. > > I understand the intent but do rules like this work? Do we end up with rules > for > the rules, for example if you are a couple of days late posting is the process > for the removal of the BSP void and it is not removed and your start again? :) > >> Afterwards, the status of the BSP/architecture is recorded in the User >> Manual. Architectures/BSPs with no response will be removed from the release >> branch and the master. The removal is recorded in the User Manual. > > I am not sure about this. The user manual is not a historical document, it is > forward facing. For example how long does this notice need to stay? > > The tiers are currently held in an INI file in rtems-tools. Maybe building the > release documentation adds the BSP's tiers as a table to the section 8.4? The > tier 5 BSPs and archs could be noted as being for removal. > > A BSP/architecture may not be removed if some maintainer shows up. This > maintainer should be recorded somewhere and its duty is to fix problems with > this BSP/architecture which show up during the development on the master > branch. > This includes tool chain problems, warnings due to compiler improvements, > driver > interface changes, CPU port API changes, new CPU port features, etc. >
Is there currently a documented process for how a BSP moves from tier 4 -> 5? Maybe it makes sense to expire a BSP for which test results are not available for a long time. In other words, add a route from tier 4 to 5 even for BSPs that still build? Historically it seems we wait for gcc to drop support or we inquire on the users mailing list whether anyone cares about a port. I can see Sebastian's perspective here, as having unused ports lying around increases our maintenance and development costs when we touch those ports. Gedare > I tend to favour the tier concept, a sort of carrot approach to the problem of > maintainer-ship. Assigned maintainers and "their duty" implies a stick and I > do > not have a stick plus the idea is linked to the first question about tracking > gcc as a service. > > Chris > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
