Open Stack

On Fri, Dec 13, 2019 at 9:18 AM Julia Kreger <juliaashleykreger at gmail.com>
wrote:

> On Fri, Dec 13, 2019 at 4:24 AM Dmitry Tantsur <dtantsur at redhat.com>
> wrote:
> >
> > Hi,
> >
> > On Thu, Dec 12, 2019 at 10:30 PM Julia Kreger <
> juliaashleykreger at gmail.com> wrote:
> >>
> >> Greetings fellow ironicans and stackers!
> >>
> >> I'd like some thoughts on the `ibmc` driver[1] that was added early
> >> this year. Specifically it merged into ironic with an operating
> >> Third-Party CI, however soon after a series of unfortunate events
> >> occurred where the Third-Party CI stopped reporting sometime in early
> >> May, and shortly their after restrictions were put into place[2]. With
> >> that being said, I feel like we should go ahead and remove this driver
> >> since it does not seem to be maintained nor tested.
> >
> >
> > Do you mean deprecate and remove in V or just straight remove? I'd
> follow the regular procedure. Otherwise, it seems that we have no other
> options :(
>
> Either... Kind of why I emailed the mailing list. :) I'd lean for
> deprecated and take that route, but maybe someone has interest in
> keeping it working
>

++ Let's follow the regular procedure unless [2] has ramifications that I
don't understand (or maybe don't want to understand).

I don't recall the regular procedure though. Was it: deprecate in cycle A
(and notify community to allow someones to step up to support), and remove
in cycle A+1? If so, let's deprecate now, in Train. We can un-deprecate if
someone comes forward.


>
> >
> > An interesting topic to discuss is how to avoid such situations when a
> driver only lives 1-2 cycles..
>
> Knowing a preference may exist for us to avoid the word support, I
> feel like it was a preview that didn't pan out. I don't feel that fear
> of this happening again should change any of our patterns moving
> forward though, since that would be the exact opposite of what is
> needed to encourage adoption.
>
>
This hopefully doesn't happen frequently, does it? It is hard to see the
future so I don't know how we could have avoided this situation. I think as
long as the driver makes sense at-the-time and meets our requirements, it
ought to land. I don't want to add more processes/steps/hurdles... :)

--ruby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191218/add92503/attachment-0001.html>