<div dir="ltr"><div><div><div><div><div><div>Hey all,<br><br></div>So I just caught up on this thread and the corresponding scrollback in IRC.<br><br></div>First of all, sorry if this came as a surprise to anybody. As Andreas pointed out this was highlighted in a number of docs email to this list, but I understand why they might have been overlooked.<br><br></div>The resource usage was indeed a concern I had in mind in implementing the DocImpact check. That is why I worked on further improvements to zuul to only need to run the test on jobs that actually use the DocImpact flag[0]. The job does, however, run in under 2min. So the total burden of boot time + 2min isn't overly high. I do completely agree with all the concerns and that it's not ideal though.<br><br></div>More than happy to have the job reverted or turned off while we discuss this further. From the discussion in IRC it sounds like there'll be a little bit of holding off until the new year (and people return from holidays) but overall there seems to be a desire to use reno to replace parts of this perhaps making the new job redundant.<br><br></div>Cheers,<br></div>Josh<br><div><div><div><br>[0] <span class="im"><a href="https://review.openstack.org/#/q/status:open+project:openstack-infra/zuul+branch:master+topic:skip-commit,n,z" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/status:open+project:openstack-infra/zuul+branch:master+topic:skip-commit,n,z</a></span></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 19, 2015 at 8:52 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 12/18/2015 02:31 PM, Andreas Jaeger wrote:<br>
> On 12/18/2015 07:45 PM, Sean Dague wrote:<br>
>> On 12/18/2015 01:34 PM, Andreas Jaeger wrote:<br>
>>> On 12/18/2015 07:03 PM, Sean Dague wrote:<br>
>>>> Recently noticed that a new job ended up on all nova changes that was<br>
>>>> theoertically processing commit messages for DocImpact. It appears<br>
>>>> to be<br>
>>>> part of this spec -<br>
>>>> <a href="http://specs.openstack.org/openstack/docs-specs/specs/mitaka/review-docimpact.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/docs-specs/specs/mitaka/review-docimpact.html</a><br>
>>>><br>
>>>><br>
>>><br>
>>> Lana talked with John Garbutt about this and announced this also in<br>
>>> several 'What's up' newsletters like<br>
>>> <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-December/081522.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-December/081522.html</a><br>
>>><br>
>>><br>
>>><br>
>>>> First, a heads up would be good. Nova burns a lot of nodes (i.e. has a<br>
>>>> lot of patch volume), so this just decreased everyone's CI capacity<br>
>>>> noticably.<br>
>>><br>
>>> I understand this reasoning and Joshua worked on a superior solution,<br>
>>> see<br>
>>> <a href="https://review.openstack.org/#/q/status:open+project:openstack-infra/zuul+branch:master+topic:skip-commit,n,z" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/status:open+project:openstack-infra/zuul+branch:master+topic:skip-commit,n,z</a><br>
>>><br>
>>><br>
>>><br>
>>>><br>
>>>> Secondly, this all seems like the wrong direction. We've got reno now,<br>
>>>> which is extremely useful for documenting significant changes in the<br>
>>>> code base that need to be reflected up. We've dropped UpgradeImpact for<br>
>>>> an upgrade comment in reno, which is *so* much better.<br>
>>>><br>
>>>> It seems like using reno instead of commit message tags would be much<br>
>>>> better for everyone here.<br>
>>><br>
>>> The goal of DocImpact is to notify the Documentation team about changes<br>
>>> - currently done via bugs in launchpad so that manuals can be easily<br>
>>> updated. How would this tracking work with docimpact?<br>
>><br>
>> Because the current concern seems to be that naked DocImpact tag leaves<br>
>> people guessing what is important. And I understand that. There is a<br>
>> whole job now to just check that DocImpact containts a reason after it.<br>
>><br>
>> We now have a very detailed system in reno to describe changes that will<br>
>> impact people using the code. It lets you do that with the commit and<br>
>> provide an arbitrarily large amount of content in it describing what and<br>
>> why you think that's important to reflect up.<br>
>><br>
>> I think it effectively deprecates all *Impact flags. Now we have a place<br>
>> for that payload.<br>
><br>
><br>
> We - Sean, Anne Gentle, and Jeremy Stanley - just discussed this on<br>
> #openstack-infra, let me summarize my understanding:<br>
><br>
> Some flags are used for checking before a merge the changes, especially<br>
> SecurityImpact and APIImpact. These are used for reviewing the changes.<br>
> This would be nice for DocImpact as well. SecurityImpact creates emails<br>
> for merged changes, DocImpact creates bugs for merged changes.<br>
><br>
> When the docimpact spec was written, reno was not in use - and later<br>
> nobody brought it up as alternative idea.<br>
><br>
> The idea going forward is instead of checking the commit message, is to<br>
> add a special section using reno that explains the changes that are<br>
> needed. A post-job would run and create bugs or sends out emails like<br>
> today whenever a new entry gets added. But this would be triggered by<br>
> special sections in the release-notes and not in the commit message. We<br>
> also expect/hope that release notes get a good review and thus the<br>
> quality of these notifications would be improved.<br>
><br>
> Let's look on how exactly we can do this next year,<br>
<br>
</div></div>Definitely.<br>
<br>
One other thing. Not running tests on commit messages has been the norm<br>
for a while. We used to have commit message checks in hacking, but they<br>
are things that you can't run locally (easily). So people push a<br>
critical fix, and run local, everything passes. They push to go to<br>
dinner and things fail. This has gotten in the way of releasing sec<br>
fixes in the past.<br>
<br>
We have also hoped that with gerrit 2.11 the event stream is rich enough<br>
that we can actually get to the point where by default we don't<br>
invalidate test results on a commit message change. There are often<br>
times when people are asked to add bug references, and the development<br>
team needs to decide if it's worth an extra couple hours (or more) of CI<br>
delay to do that. That should not have to be a trade off we need to make.<br>
<br>
Commit messages are mostly for humans (bug references being an<br>
exception). We should stick with that if we can. Especially with the<br>
potential win of keeping Jenkins results on spelling fixes in commit<br>
messages.<br>
<span class="im HOEnZb"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>