Hello,

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.

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.

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.

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

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to