Dear Johan,
Dear colleagues,
We have moved documentation for the RIPE Database WHOIS REST API out of the database software. It can be accessed at: https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API
Given the benefits associated with generated documentation, we intend to look for another solution for this at a later stage. no objection;
Since the last release there have been a number of issues reported regarding the REST API. As this is particularly important for users migrating from the old REST service to the new one, we have now addressed these issues in a bug fix release that we will put in production this week, ahead of the next major RIPE Database release. I note that the issues have not resulted in any update to the service status page - and conclude that they are not causing any serious operational impact that users would need to be warned. (The status page still has a warning and work around info for the documentation problem - and is somewhat confusing wrt to dates and announcement of a planned software update, because "today" and "tomorrow" are hard to understand correctly without clearly indicated time context).
The issues addressed by this release are listed here: https://github.com/RIPE-NCC/whois/issues?milestone=3D1&state=3Dclosed I note: 9 different issues including 2 marked as "enhancement".
For users migrating from the old REST API, we have also created a migration guide that can be found at: https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API-Migration-Guide
The bug fix release is now available in TEST Database and we intend to upgrade the production database on Thursday evening, 29 August. So this is about 48 hours of advance notice. IMHO opinion this is short - and only acceptable when an emergency upgrade is needed to address serious operational problems. For an emergency update one also would expect that it minimizes the changes to those relevant bug fixes, and avoids additional risks from unrelated changes.
The information visible to me including your language above wrt to the bugs to be fixed do not seem to indicate an emergency. If there is no emergency the defined standard process should be used. I OBJECT to ad hoc shortening of the notice time if there is no serious justification. The expected response would be to publish a revised c hange date conforming to the defined process. I agree that the definition and implementation of the new standard process need further discussion, tuning, and very likely amendments. I certainly object to the idea that the defined process will be used for "feature releases" (only), and bug fix releases can be done with short advance notice (noting the "enhancement" marks for the current changes it's not even clear that 1.68.1 ./. 1.67.4 really can qualify as a "bug fix only" update). Whether for some definition of "bug fix release" a faster track should be defined I'm not sure - specific proposals and discussion would be needed. I certainly stand by an earlier requirements statement: - all scheduled changes to the production service RIPE database software MUST be announced appropriately AT LEAST A WEEK in ADVANCE - "appropriately" implies specifically "with sufficient information to allow parties that operationally depend on automatic processes accessing the the database service to assess the risk posed by the software change to existing processes" Let me contribute one little suggestion for tuning the software management process: We should agree on standard time window [one specific day of the week and what hours] for software changes to happen; for example Friday 15:15 would be an obviously bad idea. For any user organization that has some heavy weight production process it will be helpful to plan to adapt their process schedule (and avoid ad hoc processing for every upgrade @NCC).
From my very specific point of view I would like to know what your suggested window between Wednesday noon and Thursday noon would be.
I expect some discussion of the software process at Athens; that also will include understanding of use of the test database. Anyway having advance information about upcoming software changes and discussion of the process IS a much appreciated improvement over the state of affairs before July 2013; thanks. Best regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv@NIC.DTAG.DE