[openstack-dev] [doc] DocImpact vs. reno
mzoeller at de.ibm.com
Mon Jan 11 13:30:51 UTC 2016
Tom Fifield <tom at openstack.org> wrote on 01/11/2016 01:55:21 PM:
> From: Tom Fifield <tom at openstack.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 01/11/2016 01:55 PM
> Subject: Re: [openstack-dev] [doc] DocImpact vs. reno
> On 11/01/16 20:08, Sean Dague wrote:
> > On 01/10/2016 11:31 PM, Lana Brindley wrote:
> > <snip>
> >> Wow. That'll make the release notes process painful this round ...
> > Hmmm. In my mind it will make it a lot easier. In the past we end up
> > getting to the release and sit around and go "hmmm, what did we change
> > in the last 6 months that people care about?" And forget 90% of it.
> > does the work up front. We can then just provide a final edit and
> > summary of highlights, and we're done.
> > Having spoke with ops over the years, no one is going to be upset if
> > tell them all the changes that might impact them.
> >>> Would love it to be the case, but I don't think that's correct. Or
> if it's supposed to be correct, it hasn't been well communicated :)
> >>> Few random reviews from the DocImpact queue that didn't have
> >>> https://review.openstack.org/#/c/180202/
> > I can only speak on the Nova change (as that's a team I review for).
> > You'll see this comment in there -
> > https://review.openstack.org/#/c/180202/31//COMMIT_MSG - a relnote was
> > expected for the patch series. Whether or not it managed to slip
> > through, I don't know.
> Confirmed - no relnotes for this.
> >>> https://review.openstack.org/#/c/249814/
> >>> https://review.openstack.org/#/c/250818/
> >>> https://review.openstack.org/#/c/230983/
> >>> Didn't really look closely into these - would encourage someone
> with a bit more time to do so, but the fact that these were so trivial
> to eke out means that "nearly all" is almost certainly a bad assumption.
> >> My experience would indicate that many, many DocImpact bugs are
> really not worthy of relnotes.
> > Can you provide some references? Again, my imagination doesn't really
> > come up with a lot of Nova changes that would be valid DocImpact but
> > wouldn't need a reno. I can see bugs filed against Docs explicitly
> > because there is a mismatch.
> Since you wanted to focus only on nova, here's some more DocImpact
> reviews that did not have relnotes. Again, I basically haven't read
> these - if someone wanted to do this properly, much appreciated.
At a short glance I would say:
config option needs to be set for backwards compatible change
=> should have reno file
enables snapshot for parallels. HypervisorSupportMatrix.ini is already
altered within the change => no further action necessary
Removes a deprecated config option => should have reno file
Enhances flavor extra specs => to this day I don't know how they get
documented and I'm clueless about a further action
changes default values of the policy.json => should have reno file
Does the doc change already in the change (config option help)
=> no further action necessary
introduces new config options => should have reno file
Regards, Markus Zoeller (markus_z)
More information about the OpenStack-dev