Open Stack

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.

On Thu, Aug 2, 2018 at 5:09 PM Sean McGinnis <sean.mcginnis at gmx.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180802/a9566216/attachment.html>