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. 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
