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.
Let's look on how exactly we can do this next year,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
