<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">Since I will be unable to attend the talks at the conference, I'd like to share my opinion here on the list:<br> <br> While I do like the idea of these proposed changes, specifically the database snapshots, I'd like to know if it would be possible to get an RSS feed or something of the sort that reports the upcoming changes before they're released. Also, will the releases be applied to the test environment ahead of the production environment as they currently are?<br> <br> Thanks!<br> <div class="moz-signature"><br> <span style="font-family: Arial;"> Tim Garrison<br> Software Engineer III<br> <br> <b>SoftLayer, an IBM Company</b><br> 315 Capitol Street Suite 205, Houston, TX 77002<br> 281.714.4213 direct | 713.540.4325 mobile | 281.714.4657 fax | <a class="moz-txt-link-abbreviated" href="mailto:tgarrison@softlayer.com">tgarrison@softlayer.com</a> </span><br> <br> </div> On 10/07/2013 06:31 AM, Johan Åhlén wrote:<br> </div> <blockquote cite="mid:2C0BAF9E-BB58-4D12-8F76-BFF99C0B5A08@ripe.net" type="cite"> <pre wrap="">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 </pre> </blockquote> <br> </body> </html>