Dear Johan, thanks a lot for the new much more transparent mode of software version management for the RIPE data base service. This is a huge improvement. Nevertheless I think that we need continued discussion in the community to improve mutual understanding of considerations and impact. Your message today brings up few consideratiosn from me (a bit more tuned to the general pro cess than the specific case).
We were recently made aware of some issues with the documentation related to the REST API. To fix these issues requires a new release of the Database software as some parts of the documentation are generated from the active code. The documentation is vital for anyone wanting to use the service. We therefore believe it is necessary to make a new release containing this fix only and deploy it directly to production later today. The problem description does NOT read like there IS ACTUAL SERVICE IMPACT at the moment; looking at the RIPE NCC service status page seems to confirm since it reports "no known problems" and no ser vice announcements either.
Doing a software version change with less than a day advance notice certainly can be appropriate as an "emergency update" to deal with some service impact. How much harm is done if fix to the documentation is done a few days later while a note is posted indicating that certain errors will be fixed in the near future... ?
In this particular case we don=92t believe it is necessary to put the release in test beforehand. The only fix is for the documentation and this is preventing users form using the service, so it's quite urgent. This fix should have no impact on any other part of the RIPE Database service. I am tempted to believe your assessment; I dont have access to the changes and the resources to do my own full assessment. As I did experience 3 service impacting bugs within 12 months with UNannounced version changes I conclude that I rather see than believe. I certainly do see a need to watch more carefully how software behaves after ANY change and a non zero probability of some surprise (that could result in service impact for me).
Note: knowing the schedule of upcoming changes some time in advance can be more important than actually having the ability to run tests (like due to IETF timing I could not run tests against the test server with 1.67.4 - but we did schedule preparation of critical production runs in a way that protected us against potential surprises due to the software change.)
If you have any questions then please let us know.
Kind regards,
Johan =C5hl=E9n Assistant Manager Database RIPE NCC= Best regards, Ruediger
Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv@NIC.DTAG.DE