<div dir="ltr"><div><div>So I tried to get into helping with the cinder stable tree for a while, and while I wasn't very successful (lack of time and an inability to convince my employer it should be a priority), one thing I did notice it that much of the breakage seemed to come from outside cinder - many of the libraries we depend on make backwards incompatible changes by accident, for example. Would it be possible to have a long-term-support branch where we pinned the max version of everything for the gate, pips and devtstack? I'd have thought (and I'm very willing to be corrected) that would make the stable gate, well, stable, such that it required far less work to keep it able to run a basic devstack test plus unit tests.<br><br></div>Does that sound at all sane?<br><br></div>(I'm aware there are community standards for stable currently, but a lot of this thread is the tail of standards wagging the dog of our goals. Lets figure out what we want to achieve, and figure out how we can do that without causing either too much extra work or an unnecessary fall off in quality, rather than saying we can't do anything because of how we do things now.)<br><br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 August 2016 at 08:54, Tony Breeds <span dir="ltr"><<a href="mailto:tony@bakeyournoodle.com" target="_blank">tony@bakeyournoodle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Aug 09, 2016 at 09:16:02PM -0700, John Griffith wrote:<br>
</span><span class="">> Sorry, I wasn't a part of the sessions in Austin on the topic of long<br>
> terms support of Cinder drivers.  There's a lot going on during the summits<br>
> these days.<br>
<br>
</span>For the record the session in Austin, that I think Matt was referencing,  were<br>
about stable life-cycles. not cinder specific.<br>
<span class=""><br>
> Yeah, ok... I do see your point here, and as I mentioned I have had this<br>
</span>> conversation with you and others over he years and I don't disagree.  I also don't have the ability to "force"<br>
<span class="">> said parties to do things differently.  So when I try and help customers<br>
> that are having issues my only recourse is an out of tree patch, which then<br>
> when said distro notices or finds out they don't want to support the<br>
> customer any longer based on the code no longer being "their blessed<br>
> code".  The fact is that the distros hold the power in these situations, if<br>
> they happen to own the OS release and the storage then it works out great<br>
> for them, not so much for anybody else.​<br>
<br>
</span>Right we can't 'force' the distros to participate (if we could we wouldn't be<br>
having this discussion).  The community has a process and all we can do is<br>
encourage distros and the like to participate in that process as it really is<br>
best for them, and us.<br>
<span class=""><br>
> So is the consensus here that the only viable solution is for people to<br>
> invest in keeping the stable branches in general supported longer?  How<br>
> does that work for projects that are interested and have people willing to<br>
> do the work vs projects that don't have the people willing to do the work?<br>
> In other words, Cinder has a somewhat unique problem that Nova, Glance and<br>
> Keystone don't have.  So for Cinder to try and follow the policies,<br>
> processes and philosophies you outlined does that mean that as a project<br>
> Cinder has to try and bend the will of "ALL" of the projects to make this<br>
> happen?  Doesn't seem very realistic to me.​<br>
<br>
</span>So the 'Cinder' team wont need to do all the will bending, that's for the<br>
Stable team to do with the support of *everyone* that cares about the outcome.<br>
That probably doens't fill you with hope, but that is the reality.<br>
<span class=""><br>
> Just one last point and I'll move on from the topic.  I'm not sure where<br>
> this illusion that we're testing all the drivers so well is coming from.<br>
> Sure, we require the steps and facade of 3'rd party CI, but dig a bit<br>
> deeper and you soon find that we're not really testing as much as some<br>
> might think here.<br>
<br>
</span>That's probbaly true but if we created a 'mitaka-drivers' branch of cinder the<br>
gate CI would rapidly degernate to a noop any unit/functional tests would be<br>
*entirely* 3rd party.<br>
<br>
Yours Tony.<br>
<br>______________________________<wbr>______________________________<wbr>______________<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">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div>