Dear Tim, Thanks for the input, we will for sure have a look at the possibility of using an RSS feed for the release announcements, great idea. We also thought we could use Twitter as well. When it comes to the test environment, our plan is to utilise this for public testing of major releases. We understand that there is a need for users to test their implementations when we introduce or change functionality; therefore we'll leave any major release in the TEST Database environment for a fixed time before deployment in the production RIPE Database. With bug fixes, on the other hand, we would like to apply these to the production RIPE Database as soon as they are ready. For this type of fix we would use minor releases that only contain the actual fixes and does not introduce or change expected functionality. And as always, we produce accompanying release notes detailing what is contained in all releases, whether major or minor. Kind regards, Johan Åhlén Assistant Manager Database RIPE NCC On 9 Oct 2013, at 14:55, Tim Garrison <tgarrison@softlayer.com> wrote:
Since I will be unable to attend the talks at the conference, I'd like to share my opinion here on the list:
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?
Thanks!
Tim Garrison Software Engineer III
SoftLayer, an IBM Company 315 Capitol Street Suite 205, Houston, TX 77002 281.714.4213 direct | 713.540.4325 mobile | 281.714.4657 fax | tgarrison@softlayer.com
On 10/07/2013 06:31 AM, Johan Åhlén wrote:
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