[db-wg] New bug fix release scheduled for 29 August

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 at NIC.DTAG.DE