On 8/2/2018 10:59 AM, Radomir Dopieralski wrote:
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.
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.
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.
So, I support trying to make this happen as I feel it moves us towards a
better UX for OpenStack.
On Thu, Aug 2, 2018 at 5:09 PM Sean McGinnis <[email protected]
<mailto:[email protected]>> wrote:
I'm wondering if someone on the infra team can give me some
pointers on how to
approach something, and looking for any general feedback as well.
Background
==========
We've had things like the DocImpact tag that could be added to
commit messages
that would tie into some automation to create a launchpad bug when
that commit
merged. While we had a larger docs team and out-of-tree docs, I
think this
really helped us make sure we didn't lose track of needed
documentation
updates.
I was able to find part of how that is implemented in jeepyb:
http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py
Current Challenge
=================
Similar to the need to follow up with documentation, I've seen a
lot of cases
where projects have added features or made other changes that
impact downstream
consumers of that project. Most often, I've seen cases where
something like
python-cinderclient adds some functionality, but it is on projects
like Horizon
or python-openstackclient to proactively go out and discover those
changes.
Not only just seeking out those changes, but also evaluating
whether a given
change should have any impact on their project. So we've ended up
in a lot of
cases where either new functionality isn't made available through
these
interfaces until a cycle or two later, or probably worse, cases
where something
is now broken with no one aware of it until an actual end user
hits a problem
and files a bug.
ClientImpact Plan
=================
I've run this by a few people and it seems to have some support.
Or course I'm
open to any other suggestions.
What I would like to do is add a ClientImpact tag handling that
could be added
very similarly to DocImpact. The way I see it working is it would
work in much
the same way where project's can use this to add the tag to a
commit message
when they know it is something that will require additional work
in OSC or
Horizon (or others). Then when that commit merges, automation
would create a
launchpad bug and/or Storyboard story, including a default set of
client
projects. Perhaps we can find some way to make those impacted clients
configurable by source project, but that could be a follow-on
optimization.
I am concerned that this could create some extra overhead for
these projects.
But my hope is it would be a quick evaluation by a bug triager in
those
projects where they can, hopefully, quickly determine if a change
does not in
fact impact them and just close the ones they don't think require
any follow on
work.
I do hope that this will save some time and speed things up
overall for these
projects to be notified that there is something that needs their
attention
without needing someone to take the time to actively go out and
discover that.
Help Needed
===========
From the bits I've found for the DocImpact handling, it looks like
it should
not be too much effort to implement the logic to handle a
ClientImpact flag.
But I have not been able to find all the moving parts that work
together to
perform that automation.
If anyone has any background knowledge on how DocImpact is
implemented and can
give me a few pointers, I think I should be able to take it from
there to get
this implemented. Or if there is someone that knows this well and
is interested
in working on some of the implementation, that would be very
welcome too!
Sean
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
