[openstack-dev] [tripleo] Release notes in TripleO

Emilien Macchi emilien at redhat.com
Sun Jan 15 23:11:43 UTC 2017


On Sun, Jan 15, 2017 at 1:29 PM,  <Arkady.Kanevsky at dell.com> wrote:
> Does that applies to drivers also?

It applies to every projects mentioned in the list, features / bugs
related to drivers included.

> -----Original Message-----
> From: Ben Nemec [mailto:openstack at nemebean.com]
> Sent: Wednesday, January 11, 2017 8:49 AM
> To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tripleo] Release notes in TripleO
>
>
>
> On 01/11/2017 08:24 AM, Emilien Macchi wrote:
>> On Wed, Jan 11, 2017 at 9:21 AM, Emilien Macchi <emilien at redhat.com> wrote:
>>> Greetings,
>>>
>>> OpenStack has been using reno [1] to manage release notes for a while
>>> now and it has been proven to be super useful.
>>> Puppet OpenStack project adopted it in Mitaka and since then we loved it.
>>> The path to use reno in a project is not that simple. People need to
>>> get used of adding a release note every time they submit a patch that
>>> fix a bug or add a new feature. This thing takes time and will
>>> require some involvement from the team.
>>> Though the benefits are really here:
>>> - our users will understand what new features we have developed
>>> - our users will learn deprecations.
>>> - developers will have a way to communicate with non-devs, expressing
>>> the work done in TripleO (eg: to product managers, etc).
>>>
>>> This is an example of a release note:
>>> https://github.com/openstack/puppet-nova/blob/master/releasenotes/not
>>> es/nova-placement-30566167309fd124.yaml
>>>
>>> And the output:
>>> http://docs.openstack.org/releasenotes/puppet-nova/unreleased.html
>>>
>>> So here's a plan proposal:
>>> 1) Emilien to add all CI jobs and required bits to have reno in
>>> TripleO (already done for python-tripleoclient). I'm doing the rest
>>> of the projects this week.
>>
>> I forgot to mention which projects we would target for Ocata:
>> - python-tripleoclient
>> - puppet-tripleo
>> - tripleo-common
>> - tripleo-heat-templates
>> - tripleo-puppet-elements
>> - tripleo-ui
>> - tripleo-validations
>> - tripleo-quickstart and tripleo-quickstart-extras
>
> +instack-undercloud
>
> Otherwise this all sounds good to me.  Adding reno to more tripleo projects has been on my todo list for months.
>
>>
>>> 2) Emilien with the team (please ping me if you volunteer to help) to
>>> write Ocata release notes before the release (we have ~ one month).
>>> 3) Once 1) is done, I would ask to the team to use it.
>>>
>>> Regarding 3), here are some thoughts:
>>> During pike-1 and pike-2:
>>> I wouldn't -1 a patch that does't have a release note, but rather
>>> comment and give some guidance to the committer and ask if it's
>>> something doable. Otherwise, proposing a patch on top of it with the
>>> release note. That way, we don't force people to use it immediately,
>>> but instead giving them some guidance on why and how to use it,
>>> directly in the review.
>>> During pike-3:
>>> Start -1 patches which don't have a release note. I think 3 or 4
>>> months is fair to learn how to use reno (it takes less than 5 min to
>>> create a good release note).
>>>
>>> Any feedback is highly welcome, let's make TripleO releases better!
>>>
>>> Thanks,
>>>
>>> [1] http://docs.openstack.org/developer/reno
>>> --
>>> Emilien Macchi
>>
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi



More information about the OpenStack-dev mailing list