On 12/08/2015 08:33 PM, Emilien Macchi wrote:
This morning the Puppet OpenStack had the weekly meeting [1] and we
discussed about using reno [2] for release note management.
We saw three possibilities:
1/ we use reno and enforce each contributions (bugfix, feature, etc) to
also edit a release note YAML file
2/ we use reno and the release note YAML file can be updated later (by
the contributor or someone else)
Note that this approach will somewhat complicate backporting to stable
branches (if it applies to you ofc), as you'll need release notes there
as well.
3/ we don't use reno and continue to manually write release notes
The solution 3/ is definitely not in our scope and we are willing to use
reno. Though we are looking for a way to switch using it.
Some people in our group shared some feedback, and ideas. Feel free to
comment inline:
* Having a YAML file for one feature/bugfix/... sounds heavy.
* We have 23 repositories (modules) - we will probably start using reno
for one or two modules, and see how it works.
* We will apply 2/ with the goal to go 1/ one day. We think directly
doing 1/ will have the risk to frustrate our group since not anyone is
familiar with releases. Giving -1 to a good patch just because it does
not have a release note update is not something we want now. We need to
educate people at using it, that's why I think we might go 2/.
* Using reno will spread the release note management to our group,
instead of one release manager taking care of that.
Feel free to have more feedback or comment inline, we are really willing
to suggestions.
Thanks!
[1]
https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack#Previous_meetings
(2] http://docs.openstack.org/developer/reno/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
