[openstack-dev] [doc] DocImpact vs. reno

Lana Brindley openstack at lanabrindley.com
Thu Jan 7 23:21:20 UTC 2016

> On 7 Jan 2016, at 2:09 AM, Sean Dague <sean at dague.net> wrote:
> On 01/06/2016 09:02 AM, Jeremy Stanley wrote:
>> On 2016-01-06 07:52:48 -0500 (-0500), Sean Dague wrote:
>> [...]
>>> I think auto openning against a project, and shuffling it to
>>> manuals manually (with details added by humans) would be fine.
>>> It's not clear to me why a new job was required for that.
>> The new check job was simply a requirement of the Docs team, since
>> they were having trouble triaging auto-generated bugs they were
>> receiving and wanted to enforce the inclusion of some expository
>> metadata.
> Sure, but if that triage is put back on the Nova team, that seems fine.

So you’re thinking we should make all docimpact bugs go to the project bug queue? Even for defcore?

> It also doesn't make sense to me there would be a DocImpact change that
> wouldn't also have a reno section. The reason someone thinks that a
> change needs reflection in the manual is that it adds/removes/changes a
> feature that would also show up in release notes. Perhaps my imagination
> isn't sufficient to come up with a scenario where DocImpact is valid,
> but we wouldn't have content in one of those sections.

I can think of plenty. What about where a command is changed slightly? Or an output is formatted differently? Or where flags have been removed, or default values changed, or ….

Bugs and relnotes are two very different things.


Lana Brindley

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160108/9181119f/attachment.pgp>

More information about the OpenStack-dev mailing list