On 03/09/18 14:07, Gedare Bloom wrote:
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.
I think we should demand a bit more from the user community during the
release process (e.g. test the BSPs on the release branch/candidate).
Carrying around stuff that just compiles where nobody knows if it is
still used or even runs a board just increases the cost to maintain RTEMS.
--
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
