[routing-wg] Fwd: [db-wg] Improvements to RIPE Database Software Release Management

Dear Services and Routing folks,

please see below fyi.

My apologies for the short notice and/or duplicate messages.

Regards,
Wilfried

PS: and my apologies to Wayne for selecting the wrong recipient address :-(

-------- Original Message --------
Subject: [db-wg] Improvements to RIPE Database Software Release Management
Date: Mon, 7 Oct 2013 13:31:06 +0200
From: Johan Åhlén <jahlen at ripe.net>
To: db-wg at ripe.net <db-wg at ripe.net>

Dear colleagues,

Following recent discussion regarding the release management of the RIPE Database software, we looked closely at our procedures and would
like to propose some improvements.

Together with the Database Working Group chairs, we've scheduled an informal meeting during RIPE 67, open for anyone that is interested in
this topic, to discuss the proposals and talk about how we can improve our procedures.

The meeting will take place on Monday, 14 October from 18:00-19:00 in room Sigma + Theta. We hope you will join us. Of course, you can also
send your feedback and suggestions to this list.

This is what we propose:

- Split the RIPE Database software into smaller modules. Modularisation would minimise the release frequency for our services. For instance,
with a modern API like RDAP we might have bi-weekly major releases and weekly minor releases to quickly respond to changes in the
specification. With the NRTM feed, there might be just one major release per year or even less.

- Replace the "emergency release" with a "minor release" that only contains patches for operational purposes and bug fixes. No new
functionality would be introduced and no feature changes. We would also have "major releases" where functionality is added, changed or
removed. With major releases we would keep the minimum two-week user test period leading up to the production release as stated in the
previously proposed release procedure. With any minor release, we would put it in production as soon as it's available. Most bugs affect
some users. Rather than trying to determine urgency based on numbers of users, size of users, number of networks affected, importance of
functionality affected, etc., we would treat all bugs the same. In short, if someone reports an issue to us, we fix it right away. This
process has generally worked well over recent years.

- Improve the test environment. We know that users would like to have their real data to do proper testing. To solve this issue, we propose
to use snapshots of the current database for this purpose.

- Improve communication surrounding new releases. This covers all documentation and how we inform users about changes.

We hope that you find this way forward beneficial.

Kind regards,

Johan Åhlén
Assistant Manager Database
RIPE NCC