Open Stack

I’m late to this party because holidays (Thanks Anne for bringing it to my attention).

First of all, sorry this came as a surprise. I tried hard to make sure everyone who needed to know knew, but that’s naturally a difficult thing to do.

To the implementation details: I really am struggling to see how Reno could be used as a DocImpact replacement, unless you’re going to use it to somehow enforce that packages with DocImpact include some kind of text file in the commit. That would be complete overkill, and has the potential to really mess up the development repos (who needs random text files littered around?). Maybe I’m missing something here, though.

Really, the intent of the job is merely to check for a description after the DocImpact tag that gives the docs people a hint as to what you were thinking when you added the tag. It’s simply a time saving measure on our part, and sometimes a thing that saves a large amount of human time needs to take a small amount of compute time. I don’t think that’s a big ask, but again, please correct me if I’m wrong.

In short, I would rather remove the DocImpact facility entirely than try and turn a tool designed for a completely different task to this problem. However, as this is the first complaint I’ve seen about this solution since starting working on this thorny problem nearly a year ago, I can’t help but wonder if we’re overreacting? Do people genuinely hate this solution enough that we need to go back to the drawing board?

Lana

> On 22 Dec 2015, at 10:33 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> 
> Excerpts from Andreas Jaeger's message of 2015-12-18 20:31:04 +0100:
>> On 12/18/2015 07:45 PM, Sean Dague wrote:
>>> On 12/18/2015 01:34 PM, Andreas Jaeger wrote:
>>>> On 12/18/2015 07:03 PM, Sean Dague wrote:
>>>>> Recently noticed that a new job ended up on all nova changes that was
>>>>> theoertically processing commit messages for DocImpact. It appears to be
>>>>> part of this spec -
>>>>> http://specs.openstack.org/openstack/docs-specs/specs/mitaka/review-docimpact.html
>>>>> 
>>>> 
>>>> Lana talked with John Garbutt about this and announced this also in
>>>> several 'What's up' newsletters like
>>>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081522.html
>>>> 
>>>> 
>>>>> First, a heads up would be good. Nova burns a lot of nodes (i.e. has a
>>>>> lot of patch volume), so this just decreased everyone's CI capacity
>>>>> noticably.
>>>> 
>>>> I understand this reasoning and Joshua worked on a superior solution,
>>>> see
>>>> https://review.openstack.org/#/q/status:open+project:openstack-infra/zuul+branch:master+topic:skip-commit,n,z
>>>> 
>>>> 
>>>>> 
>>>>> Secondly, this all seems like the wrong direction. We've got reno now,
>>>>> which is extremely useful for documenting significant changes in the
>>>>> code base that need to be reflected up. We've dropped UpgradeImpact for
>>>>> an upgrade comment in reno, which is *so* much better.
>>>>> 
>>>>> It seems like using reno instead of commit message tags would be much
>>>>> better for everyone here.
>>>> 
>>>> The goal of DocImpact is to notify the Documentation team about changes
>>>> - currently done via bugs in launchpad so that manuals can be easily
>>>> updated. How would this tracking work with docimpact?
>>> 
>>> Because the current concern seems to be that naked DocImpact tag leaves
>>> people guessing what is important. And I understand that. There is a
>>> whole job now to just check that DocImpact containts a reason after it.
>>> 
>>> We now have a very detailed system in reno to describe changes that will
>>> impact people using the code. It lets you do that with the commit and
>>> provide an arbitrarily large amount of content in it describing what and
>>> why you think that's important to reflect up.
>>> 
>>> I think it effectively deprecates all *Impact flags. Now we have a place
>>> for that payload.
>> 
>> 
>> We - Sean, Anne Gentle, and Jeremy Stanley - just discussed this on
>> #openstack-infra, let me summarize my understanding:
>> 
>> Some flags are used for checking before a merge the changes, especially
>> SecurityImpact and APIImpact. These are used for reviewing the changes.
>> This would be nice for DocImpact as well. SecurityImpact creates emails
>> for merged changes, DocImpact creates bugs for merged changes.
>> 
>> When the docimpact spec was written, reno was not in use - and later
>> nobody brought it up as alternative idea.
>> 
>> The idea going forward is instead of checking the commit message, is to
>> add a special section using reno that explains the changes that are
>> needed. A post-job would run and create bugs or sends out emails like
>> today whenever a new entry gets added. But this would be triggered by
>> special sections in the release-notes and not in the commit message. We
>> also expect/hope that release notes get a good review and thus the
>> quality of these notifications would be improved.
> 
> So you want to add a special section to the reno note file, similar to
> "upgrade" and "fixes" but to replace documentation impact notes? What
> would use the contents?
> 
> Doug
> 
>> 
>> Let's look on how exactly we can do this next year,
>> 
>> Andreas
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
Lana Brindley
writer:speaker:blogger
http://lanabrindley.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160105/7d82b8d3/attachment.html>
-------------- 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/20160105/7d82b8d3/attachment.pgp>