On Mon, Sep 3, 2018 at 8:06 AM, Gedare Bloom <ged...@rtems.org> wrote: > 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 This should be "route from tier 3 to 5".
> 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
