<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 8/2/2018 10:59 AM, Radomir
Dopieralski wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAF_JR34KmuNTy-aWXXaKS54B9=A5-DSbGH222E3NOY=x6UZnPQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">To be honest, I don't see much point in
automatically creating bugs that nobody is going to look at.
When you implement a new feature, it's up to you to make it
available in Horizon and CLI and wherever else, since the people
working there simply don't have the time to work on it. Creating
a ticket will not magically make someone do that work for you.
We are happy to assist with this, but that's it. Anything else
is going to get added whenever someone has any free cycles, or
it becomes necessary for some reason (like breaking
compatibility). That's the current reality, and no automation is
going to help with it. </div>
<br>
</blockquote>
I disagree with this view. In the past there have been companies
that have had people working on Horizon to keep it implemented for
their purposes. Have these bugs available would have made their
work easier. I also know that there are people on the OSC team that
just work on keeping functions implemented and up to date.<br>
<br>
At a minimum, having these bugs automatically opened would help when
someone is trying to figure out why the new function they are
looking for is not available in OSC or Horizon. A search would turn
up the fact that it hasn't been implemented yet. Currently, we
frequently have the discussion 'Has that been implemented in Horizon
yet?' This would reduce the confusion around that subject.<br>
<br>
So, I support trying to make this happen as I feel it moves us
towards a better UX for OpenStack.<br>
<br>
<blockquote type="cite"
cite="mid:CAF_JR34KmuNTy-aWXXaKS54B9=A5-DSbGH222E3NOY=x6UZnPQ@mail.gmail.com">
<div class="gmail_quote">
<div dir="ltr">On Thu, Aug 2, 2018 at 5:09 PM Sean McGinnis <<a
href="mailto:sean.mcginnis@gmx.com" moz-do-not-send="true">sean.mcginnis@gmx.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I'm
wondering if someone on the infra team can give me some
pointers on how to<br>
approach something, and looking for any general feedback as
well.<br>
<br>
Background<br>
==========<br>
We've had things like the DocImpact tag that could be added to
commit messages<br>
that would tie into some automation to create a launchpad bug
when that commit<br>
merged. While we had a larger docs team and out-of-tree docs,
I think this<br>
really helped us make sure we didn't lose track of needed
documentation<br>
updates.<br>
<br>
I was able to find part of how that is implemented in jeepyb:<br>
<br>
<a
href="http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py</a><br>
<br>
Current Challenge<br>
=================<br>
Similar to the need to follow up with documentation, I've seen
a lot of cases<br>
where projects have added features or made other changes that
impact downstream<br>
consumers of that project. Most often, I've seen cases where
something like<br>
python-cinderclient adds some functionality, but it is on
projects like Horizon<br>
or python-openstackclient to proactively go out and discover
those changes.<br>
<br>
Not only just seeking out those changes, but also evaluating
whether a given<br>
change should have any impact on their project. So we've ended
up in a lot of<br>
cases where either new functionality isn't made available
through these<br>
interfaces until a cycle or two later, or probably worse,
cases where something<br>
is now broken with no one aware of it until an actual end user
hits a problem<br>
and files a bug.<br>
<br>
ClientImpact Plan<br>
=================<br>
I've run this by a few people and it seems to have some
support. Or course I'm<br>
open to any other suggestions.<br>
<br>
What I would like to do is add a ClientImpact tag handling
that could be added<br>
very similarly to DocImpact. The way I see it working is it
would work in much<br>
the same way where project's can use this to add the tag to a
commit message<br>
when they know it is something that will require additional
work in OSC or<br>
Horizon (or others). Then when that commit merges, automation
would create a<br>
launchpad bug and/or Storyboard story, including a default set
of client<br>
projects. Perhaps we can find some way to make those impacted
clients<br>
configurable by source project, but that could be a follow-on
optimization.<br>
<br>
I am concerned that this could create some extra overhead for
these projects.<br>
But my hope is it would be a quick evaluation by a bug triager
in those<br>
projects where they can, hopefully, quickly determine if a
change does not in<br>
fact impact them and just close the ones they don't think
require any follow on<br>
work.<br>
<br>
I do hope that this will save some time and speed things up
overall for these<br>
projects to be notified that there is something that needs
their attention<br>
without needing someone to take the time to actively go out
and discover that.<br>
<br>
Help Needed<br>
===========<br>
From the bits I've found for the DocImpact handling, it looks
like it should<br>
not be too much effort to implement the logic to handle a
ClientImpact flag.<br>
But I have not been able to find all the moving parts that
work together to<br>
perform that automation.<br>
<br>
If anyone has any background knowledge on how DocImpact is
implemented and can<br>
give me a few pointers, I think I should be able to take it
from there to get<br>
this implemented. Or if there is someone that knows this well
and is interested<br>
in working on some of the implementation, that would be very
welcome too!<br>
<br>
Sean<br>
<br>
__________________________________________________________________________<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" moz-do-not-send="true">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" moz-do-not-send="true">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>