On 10/02/2014 04:47 AM, Ihar Hrachyshka wrote: > Hi, > > I guess the following review is meant: > https://review.openstack.org/#/c/125075/ > > I went thru each of the failure for the patch (no dependency failures > checked), and here are some damned lies (c) about those failures: > > - bug 1323658: 2 failures (ssh connection timeout issue, shows up in > Neutron jobs) > - bug 1331274: 2 failures (Grenade not starting services) > - bug 1375108: 4 failures (bug in Nova EC2 reboot code?) > - bug 1348204: 1 failure (Cinder volume detach failing) > - bug 1374175: 1 failure (Heat bug) > > Neither of those bugs are solved in master. Some of those bugs are > staying opened for months. The first bug was raised as Neutron bug and > marked for RC-1, but then was untargeted due to believe among Neutron > developers that it's a bug in Tempest. > > Nevertheless, with all the hopeless state of the gate, in the Icehouse > release scheduled for today stable maint team was able to merge fixes > for more than 120 bugs. > > So, all that said, does anyone believe that it's fair to bitch about > stable maintainers not doing their job? Wouldn't it be more fair to > bitch about the overall hopeless state of the gate and projects > feeling ok releasing Juno with major failures in gate (like in case of > the very first bug in the list)? > > /Ihar
Fwiw, this whole patch stream is part of the fix for #1331274 in Juno / Master (we need to get off of screen in grenade to have been process control) - https://review.openstack.org/#/q/status:open+project:openstack-dev/devstack+branch:stable/icehouse+topic:no_screen,n,z and in order to merge any devstack icehouse changes we needed to fix the tox bashate targets (https://review.openstack.org/#/c/125075/ is actually a trivial additional add, so it made a really good indication that this was latent state). After those fails on this patch - we correctly disabled grenade on icehouse (it should have been turned off when havana eoled, there was a delay) - https://review.openstack.org/#/c/125371/ I made a bunch of noise about #1323658 in the project meeting, spent a bunch of time on chasing that after, I agree that punting on it for the release was a very questionable call. I proposed the skip - https://review.openstack.org/#/c/125150/ which was merged. I marked #1374175 as critical for the heat team - https://bugs.launchpad.net/heat/+bug/1374175 - also skipping it is working it's way through the gate now - https://review.openstack.org/#/c/125545/. Joe, Matt Treinish, and I looked at #1375108 last night, and found that the test author had recheck grinded their test in ... even when it failed in related areas. So that was straight reverted - https://review.openstack.org/#/c/125543/ I have not looked into 1348204 at all - I just bumped it up to critical. Looks like Matt Riedeman has a debug patch out there. ... But that seems to answer the question I was asking. Who's maintaining this seems to be me (or more specifically the same people that are always working these bugs, me, joe, matt, and matt). I don't want it to be me. Because as soon as I manage to get the infrastructure for fixing #1331274 I want nothing more to do with icehouse stable. What I'm complaining about is that until I spent time on #1331274 no one seemed to understand that devstack patches aren't mergable (and hadn't been for weeks). If stable was maintained I'd expect that someone would actually know the current state, or be helping with it. Also icehouse is about to no longer be installable with pip because of pip changes. https://review.openstack.org/#/c/124648/ has to land to fix that, other devstack patches have to land to get us there. If stable branches are important to the project, then stable branches need to be front and center in the weekly project meeting. Maintaining a thing is actually knowing the current status and working to make it better. Removing tests is a totally fine thing to propose, for instance. But the point is, raised well by Alan, the stable branches are basically only being worked on by one distro, and no other vendors. So honestly, if that doesn't change, I'd suggest dropping all but the most recent one (so we can test upgrade testing for current master). -Sean -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
