Tuesday, 2015-02-24

*** pixelb has quit IRC00:13
*** pixelb has joined #openstack-stable00:15
*** zul has quit IRC00:51
*** zul has joined #openstack-stable00:52
*** adam_g is now known as adam_g_out01:09
*** devlaps has quit IRC01:11
*** david-lyle is now known as david-lyle_afk01:19
*** jamielennox is now known as jamielennox|away01:46
*** jamielennox|away is now known as jamielennox02:12
*** pixelb has quit IRC03:31
*** apevec has quit IRC03:32
*** devlaps has joined #openstack-stable04:17
*** devlaps has quit IRC05:17
*** jamielennox is now known as jamielennox|away05:33
*** jamielennox|away is now known as jamielennox05:34
*** mrunge has joined #openstack-stable06:47
*** e0ne has joined #openstack-stable07:50
*** prometheanfire has quit IRC07:57
*** prometheanfire has joined #openstack-stable08:09
*** eglynn has joined #openstack-stable08:16
*** pixelb has joined #openstack-stable08:37
*** derekh has joined #openstack-stable09:20
*** takedakn has joined #openstack-stable09:59
*** ihrachyshka has joined #openstack-stable10:06
*** jamielennox is now known as jamielennox|away10:42
*** takedakn has quit IRC10:57
*** jamielennox|away is now known as jamielennox10:58
*** apevec has joined #openstack-stable10:59
*** jamielennox is now known as jamielennox|away11:01
*** jamielennox|away is now known as jamielennox11:02
*** subscope has quit IRC11:05
apevecihrachyshka, updated in all branches: https://review.openstack.org/#/q/I3b8845ad8e013cf6747995df5a62cc4f2ee85e01,n,z11:06
apevecicehouse will need squashing, we'll see about juno11:07
ihrachyshkaapevec, thanks!11:07
ihrachyshkaapevec, I think juno is still ok11:07
*** jamielennox is now known as jamielennox|away11:08
apevecwe'll see once 158627 returns11:08
*** jamielennox|away is now known as jamielennox11:10
* apevec watches https://jenkins03.openstack.org/job/check-requirements-integration-dsvm/470/consoleFull11:10
apevecihrachyshka, nice thread  [stable][all] Revisiting the 6 month release cycle + related danpb's essay11:13
*** jogo has joined #openstack-stable11:14
ihrachyshkaapevec, I call BS11:14
ihrachyshkaapevec, I need to find time to chime in there11:15
apevecsame here11:15
ihrachyshkattx voice is the sane one there11:15
apevecalso this will probably turn into 100 posts monster threads soon11:15
ttxthe trick is, we are outnumbered by devs11:16
ihrachyshkaapevec, right, I'm afraid those with a lot of time to argue will get what they want11:16
ttxof course tagging every 2 weeks or not releasing will be convenient to them11:16
*** eglynn is now known as eglynn-afk11:16
apevecfrankly, we'd never need stable branches if upgrades were actually working :)11:16
apeveclike in yum update11:16
*** subscope has joined #openstack-stable11:17
ihrachyshkattx, I wouldn't say I'm outnumbered by devs, I'm one of them. maybe with a bit different perspective.11:18
ttxihrachyshka: right, by dev I mean, people only focused on development and not doing any other type of work11:19
apevecthose who want to ignore "One mistake and you have to support it for the rest of your life."11:20
jokke_++11:22
jokke_The more I look this circus the more I think Linux kernel with single dictator looking after the interests is not that bad thing11:23
*** eglynn-afk has quit IRC11:26
apevecihrachyshka, so juno will need squash too, git diff fix alone failed check11:31
apevecwatching now https://jenkins07.openstack.org/job/check-requirements-integration-dsvm/477/console11:31
ihrachyshkaapevec, link?11:31
*** takedakn has joined #openstack-stable11:31
ihrachyshkaack11:31
ihrachyshkahm, is it the link?11:32
apevecihrachyshka, consoleFull link above is where it failed11:32
*** takedakn has quit IRC11:32
apeveclast link is check with both patches in juno11:32
apevecwhich should succeed11:32
*** takedakn has joined #openstack-stable11:32
ihrachyshkaapevec, aha, now taskflow11:33
apevecyeah, 'enum34' is not in global-requirements.txt11:33
apevecadam's patch should fix that11:33
ihrachyshkaapevec, you stacked the patches?11:34
apevecyes, shown nicely in zull11:34
apevecbummer 158276 fails in dsvm-cells11:36
*** takedakn has quit IRC11:36
Davieyhmm, which thread are you talking about?11:36
DavieySubject: juno is fubar?11:36
ihrachyshkaDaviey,  [stable][all] Revisiting the 6 month release cycle11:38
ihrachyshkaDaviey, plus multiple threads around it11:38
Davieyoh11:38
*** jamielennox is now known as jamielennox|away11:38
ihrachyshka(people like to make things harder by spawning separate threads)11:39
apevecFailed to fetch http://mirror.rackspace.com/ubuntu/pool/...11:39
*** takedakn has joined #openstack-stable11:40
*** takedakn has quit IRC11:40
*** jamielennox|away is now known as jamielennox11:41
apevecis dsvm-cells voting ?11:43
Davieyttx: Just to check, you are happy with status quo?11:43
*** kashyap has joined #openstack-stable11:47
kashyapFWIW, I find DamPB's reasoning to Theirry's comments (on the "Reevaluating" thread) very convincing w.r.t more releases != more work.11:49
ihrachyshkakashyap, I find it hilarious that people advocate for less pre-release testing while they already ship software unusable release after release (and we spend weeks to stabilize and fix features that were not even properly implemented in upstream). look at neutron juno: ipv6 is completely broken, l3 ha is almost broken...11:53
ihrachyshkaand then we get those fixed for the 2nd point release of "stable"11:53
kashyapihrachyshka, To raise another storm, I don't even know if features like "HA" belong in core integrated features11:54
ihrachyshkahow stable is a stable release that does have features broken for months?11:54
kashyapihrachyshka, But, I see what you're saying. . .11:54
ihrachyshkakashyap, for ha, I agree11:54
ihrachyshkakashyap, but that's irrelevant to the topic of stable11:54
kashyapYes, agreed on irrelevance, hence the disclaimer.11:54
ihrachyshkakashyap, if I would to decide, I would advocate for MORE testing, LESS features. for they land unusable11:55
kashyapihrachyshka, Also, I find it pervasive that - most only want to do "features", and no bug fixing?!?!11:55
kashyapLook at the bug trackers (agreed, some are really, really poor quality bugs which make you ignore them) -- still, very less triaging11:56
ihrachyshkakashyap, for kilo, neutron is going to ship something called prefix delegation for ipv6, which won't be actually tested in gate because dibbler client that it relies on requires some not upstreamed patches. so no tempest, no scenarios. is it responsible?11:56
kashyapihrachyshka, Mind you, I'm totally with you on "Less is more" -- and mentioned it on the list too on a previous thread11:56
ihrachyshkakashyap, right, we have some advocates of 'no features' in neutron. respectively, me and Maru (both from redhat...)11:56
kashyapihrachyshka, So what if both are from RH, it doesn't matter as long as there's merit in the idea (and there is!)11:57
kashyapI also absolutely don't like the fragility -- sneeze and your deployment falls apart nature.11:58
ihrachyshkakashyap, I mean, redhat seems to be on the opposite side of interests. we feel how it actually works when upstream drops the idea of stable releases, vulnerability management, responsible testing, ...11:58
kashyapihrachyshka, No one is saying to totally 'drop' the idea of stable releases, VMT, and testing - that's just madness11:59
kashyapSelective VMT idea sounds reasonable too, to me.11:59
ihrachyshkakashyap, I tell you, if there are no stable branches and VMT for 'claimed to be stable' 2month releases, then they are not really to be consumed by users.12:00
kashyapResponsible testing - yes - at-least a few 'critical path' (open source only, I don't really care about proprietary, very obviously) deployments. . .12:00
ihrachyshkakashyap, again, neutron side, we don't even gate for linuxbridge :)12:01
kashyapihrachyshka, I think I heard you mention that on the list (about linuxbridge)12:01
kashyapHmm12:01
ihrachyshkakashyap, so, for the end user, what's the different between kilo-1 milestone tarballs and 2month 'stable' release? for both of them, there are no stable branches, no VMT, and no any reasonable stability guarantees.12:04
ihrachyshkakashyap, the only difference for developers seems to be that they land features in any milestone. which is something they decide inside the teams. for neutron, we land stuff till rc1, I don't see a problem here. if nova decided to stop at kilo-2, fine, that's their choice.12:05
* kashyap reading the scroll, got distracted12:05
kashyapihrachyshka, " reasonable stability guarantees." -- why would we say this? The 'gating' assures (to some definitions) that out of the box, for all open source drivers, it doesn't blow up if you configure12:06
kashyapAgreed, but that's bare minimal12:06
ihrachyshkakashyap, for real stable branches, we also test upgrade12:07
kashyapVia granade I assume12:07
ihrachyshkaright12:07
ihrachyshkaapevec, adam's patch backport succeeded in juno, so we can squash12:11
ttxDaviey: statu quo in ? 6-month release cycles ?12:15
ttxNot really happy (and I think we could try to release more often) -- it's just that proposals are generally myopic and only consider one side12:16
ttxPeople think it's an arbitrary choice, while it's more a trade-off12:17
jokke_Hmm-m reading the past hours backlog ... I think one thing we could take from this discussion12:18
*** eglynn-afk has joined #openstack-stable12:19
jokke_"""11:50 < ihrachyshka> and then we get those fixed for the 2nd point release of "stable"""" This one catched me ... how about we stop doing this, I mean set releases of our stables12:19
ttxright, I don't think there is much value in stable point releases12:20
ttxThey are just convenient ways of beating the drum12:20
jokke_lets start rolling stable being "Juno is Juno" and release stable point releases on project basis when there is need/sense for it12:20
ihrachyshkaon that one, I probably agree. as an upstream, we don't get much value from point releases (other than having a more clear idea on which patches are guaranteed to be included in a build)12:21
jokke_so if there is some critical security fix for Nova, that will trigger Nova point release and we're expecting that still being compatible with major12:21
ihrachyshkabut also I don't see a big problem with releasing them.12:22
ihrachyshkait's not a big deal I guess (comparing to other work around branches)12:22
jokke_I do like the point releases as they are easy way to track changelogs etc.12:22
apevecihrachyshka, are you squashing already or shall I go ahead?12:22
ihrachyshkaapevec, you go ahead :)12:22
apevecack12:22
ihrachyshkathanks12:22
jokke_I mean lets not do them just because calendar says it's time ... lets turn the point releases more towards the lib releases when the release is done when it's convenient to do12:23
apevecihrachyshka, and ack on removing coordinated point releases, should be up to $project-maint team12:23
apeveclike for clients12:23
apevecjokke_, +112:23
jokke_I think that would take some burden off from the stable-maint as well12:24
apevecfor example, I'm moving again icehouse point release because gate is stuck12:24
apevecjokke_, right, central stable-maint should be overseeing stable policy is adhered to12:25
apeveci.e. -2 liberary12:25
jokke_apevec: you probably have the best general idea of the next icehouse point. Is this the right point to push out the pooint release for all or is there for example projects which should have been out there month ago or perhaps wouldn't need it at all?12:25
jokke_apevec: with the lib release I was referring just to that same as clients not having set dates for coordinated releases12:27
apevecfor example, trove should just skip icehouse point release https://review.openstack.org/#/q/status:merged+branch:stable/icehouse+project:openstack/trove,n,z12:28
apeveconly gate fixing/reqs changes...12:28
apevecthey did skip juno point releases iirc12:28
jokke_:D12:29
apevecalso sahara .3 was useless: https://review.openstack.org/#/q/status:merged+branch:stable/juno+project:openstack/sahara,n,z12:29
apevecbetween .2 and .3 only reqs sync...12:29
ihrachyshkaapevec, reqs sync are sometimes valuable though12:29
ihrachyshkaapevec, giving indication to packagers that they should revisit the deps12:30
apevecyes, but not enough to trigger point release12:30
apevecthey can look in git12:30
apeveccorrection, it was Sahara juno .212:30
apevec.3 is next12:30
*** eglynn-afk is now known as eglynn12:31
apevecbut bad was that they actually had patches lined up for .2 https://review.openstack.org/#/q/status:open+project:openstack/sahara+branch:stable/juno,n,z12:31
apevecsee comment in 15082512:32
apeveczul, ^12:32
ihrachyshkawtf, why do people setting -2 don't respond12:32
apevecihrachyshka, afaik zul didn't use adam's freeze script which records -2s12:33
ihrachyshkaI think we should have a way to revoke -2 for those reviews independent from the person who set it.12:33
apevecscript has an option to remove those freeze -2s later12:33
ihrachyshkaI know12:33
ihrachyshkabut that should not be a problem of those backporters :|12:33
apevecif you do them manually, you forget them12:33
apevecyeah, it's too bad12:34
ihrachyshkabut you get emails in your inbox asking to remove -212:34
ihrachyshkaand you don't respond for month12:34
ihrachyshkaoh well12:34
apeveclost in spam probably :(12:34
ihrachyshkanot month12:34
ihrachyshkabut still12:34
apevecyeah, mail filters ftw12:34
apevecI'd like everyone set from:apevec => HIGH12:35
ihrachyshkait ain't a hard thing, I always start my morning with reading ALL gerrit emails12:35
ihrachyshka(except CIs)12:35
zulapevec:  done sorry about that12:40
apeveczul, thanks! sahara stable-main just got new members, they'll be able to handle their backports now12:40
zulok12:41
ihrachyshkaapevec, so do we have a way to forcefully revoke votes?12:42
apevecnot that I know, short of asking infra12:42
apevecttx, ^ ?12:42
ihrachyshkaapevec, btw where is the -2 script documented? I don't see it at https://wiki.openstack.org/wiki/StableBranchRelease12:43
apevecihrachyshka, then it needs to be added12:43
ihrachyshkaapevec, I don't have knowledge to do it though12:44
ihrachyshkahaven't ever being a release engineer (and not looking fwd to it)12:44
ihrachyshka*been12:44
apevecok, I'll document it when using it for next . release12:44
ihrachyshkathanks12:44
ttxapevec: I think infra can unset votes yes12:50
apevecihrachyshka, I don't think waiting for 158276 recheck is worthy, cells failure was unrelated so I'm squashing icehouse12:53
ihrachyshka++12:54
apevecalright, https://review.openstack.org/157606 is now ready to pass and remove RED BROKEN BUSTED from https://etherpad.openstack.org/p/stable-tracker13:02
ihrachyshkaapevec, do you have juno counterpart?13:03
apevecjuno fixes are squashed into https://review.openstack.org/15862713:03
ihrachyshkathanks13:04
apevecihrachyshka, looking at https://bugs.launchpad.net/devstack/+bug/1264422 git diff bug was long known and fixed in different parts of openstack...13:08
openstackLaunchpad bug 1264422 in devstack "stack.sh overwrites local changes" [Undecided,Fix released] - Assigned to IWAMOTO Toshihiro (iwamoto)13:08
ihrachyshkaapevec, yeah...13:10
ihrachyshkaapevec, I wonder why it started to show up this year only13:10
ihrachyshkaapevec, there was a minor version bump for git package in precise this Jan13:10
ihrachyshkaapevec, maybe it's somehow related13:10
ihrachyshkaapevec, though I've looked thru the list of patches between git version and haven't found anything relevant13:11
ihrachyshkathough obviously I'm not an expert in git code :)13:11
ihrachyshkaapevec, +2 to both squashes, waiting for jenkins +1 to approve13:11
apevecI saw mentioned it's a race13:11
apevecbut what I don't like that workarounds are not propagated across projects...13:12
apevectoo much balkanization?13:12
ihrachyshkaI guess yes, no one is really aware about all moving parts that are affected13:13
ihrachyshkato grasp it in this case, you should be deep in QA business13:13
*** Adri2000 has quit IRC13:17
*** Adri2000 has joined #openstack-stable13:17
*** jamielennox is now known as jamielennox|away13:18
*** jamielennox|away is now known as jamielennox13:20
*** zul has quit IRC14:23
*** zul has joined #openstack-stable14:24
*** eglynn has quit IRC15:02
*** eglynn has joined #openstack-stable15:05
*** devlaps has joined #openstack-stable15:24
*** devlaps has quit IRC15:24
*** david-lyle_afk is now known as david-lyle15:47
*** mrunge is now known as mrunge_afk15:49
*** mrunge_afk has quit IRC15:49
*** zul has quit IRC15:50
*** zul has joined #openstack-stable15:50
*** jamielennox is now known as jamielennox|away16:15
*** jamielennox|away is now known as jamielennox16:16
apeveclol chrome sent me to stabletracker.com16:31
ihrachyshkaapevec, woot all unbreaking patches merged16:32
apevecyep, just wanted to update etherpad16:32
apevecihrachyshka, what color shall it be?16:32
apevecyellowish?16:32
ihrachyshka:D16:32
ihrachyshkapink16:32
apevecPINKish (unblocked, known non-stable-only problems)16:34
*** apevec has quit IRC16:48
*** ihrachyshka has quit IRC17:07
*** rwsu-afk is now known as rwsu17:18
*** kashyap has left #openstack-stable17:35
*** derekh has quit IRC17:44
*** apevec has joined #openstack-stable17:56
*** eglynn is now known as eglynn-afk18:00
*** ihrachyshka has joined #openstack-stable18:00
adam_g_outapevec, ihrachyshka \o/ nice!18:02
*** devlaps has joined #openstack-stable18:11
*** zul has quit IRC18:52
*** zul has joined #openstack-stable18:52
*** zul has quit IRC18:53
*** zul has joined #openstack-stable18:53
*** eharney has joined #openstack-stable19:24
*** apevec has quit IRC19:28
*** devlaps has quit IRC19:33
*** e0ne has quit IRC19:43
*** eharney has quit IRC19:46
*** apevec has joined #openstack-stable20:19
*** eglynn-afk is now known as eglynn20:28
*** pixelb has quit IRC20:36
*** ihrachyshka has quit IRC21:03
*** ihrachyshka has joined #openstack-stable21:06
*** eglynn has quit IRC22:07
SergeyLukjanovapevec, yeah, we've missed the .2 milestone, now have several folks in stable maint, so, should handle all needed backports22:16
*** ihrachyshka has quit IRC22:31
*** apevec has quit IRC22:57

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!