[15:37] blackboxsw: rharper: https://github.com/isaacs/github/issues/1303#issuecomment-595231303 looks relevant [15:38] Odd_Bloke: oi! [15:38] So it sounds like GitHub changed behaviour, and has now reverted that change due to it causing exactly the sort of issue that we saw. [15:38] "We made a change yesterday that will be causing that." [15:38] dang [15:38] And Fred was just unlucky when it came to the timing of the merge. [15:38] so, in the face of that, do we still want to leave it as it is? or force push to fix ? [15:39] I think we should make very sure we attribute Fred in the release notes/changelog appropriately, but I don't think a force push is worth it for this, frustrating as that is for Fred. [15:39] "By doing so, you have the last word in "authoring" the resulting squashed commit." -- so if the sqaush/merger has the last word; it's not clear to me how we make sure it's the PR author in there; do we include Author: <...> in the commit message ? [15:40] They've reverted the change, so I don't think we need to do anything. [15:41] https://github.com/isaacs/github/issues/1303#issuecomment-595595284 is the latest info. [15:41] heh, until it is; I guess the fact that in the UI it's not clear who is getting the Authorship is my concern [15:41] "the PR author becomes the squashed commit's author" [15:41] right; I wonder how we can see that in the UI [15:41] I don't know that we can. [15:41] =( [15:42] someone gets to be unlucky again [16:41] Yeah. :/ [16:49] Did one of us cause https://github.com/canonical/cloud-init/pull/236 to be submitted? [16:50] Odd_Bloke: I was wondering that too. [16:50] not me [16:50] powersj: ? [16:50] figured we'd talk in github meeting today [16:50] yeah [16:50] not I said the fly [16:50] lol [16:51] and did this rennovate plugin also cause/trigger the 'wip' action to run on https://github.com/canonical/cloud-init/pull/214 [16:52] or is the wip action another magic 'thing' that just showed up too [16:52] separately [16:52] I think someone installed it for the canonical org and enabled it for us as well [16:53] Aha, that makes sense. [17:14] thanks for the review rharper on https://github.com/canonical/cloud-init/pull/214 addressed comments (and dropped a bunch of duplicated doc content I hadn't meant to preserve [17:18] * blackboxsw is only ec2 secondary ipv4/ipv6 support branch https://github.com/canonical/cloud-init/pull/214 [17:18] then will hit the review queue for cloud-init [17:19] I mean ec2 PR is https://github.com/canonical/cloud-init/pull/114 [17:19] https://getyarn.io/yarn-clip/1c229570-cf51-4374-8dd2-55648e940164 [18:17] smoser: Thanks for the review on that pytest branch, we definitely ended up in a better place as a result. :) [18:18] blackboxsw: Your request changes (on https://github.com/canonical/cloud-init/pull/211) is blocking it from landing, could you take a look when you have a minute? [19:04] Odd_Bloke: definitely. rharper I see you approved https://github.com/canonical/cloud-init/pull/214 [19:04] blackboxsw: yes, looks good now [19:04] so my question really is, (given ubuntu feature freeze) what we should do with 214 and 211 [19:04] we landed and uploaded our bug fixes, right ? [19:04] and 214 has an FFE< right ? [19:05] rharper: bug fixes are landed, and 214 is FFe [19:05] but 211 should probably land too, but it's not an FFe or bug-fix really [19:05] we have two ffes right ? [19:05] are they both done yet ? [19:05] rharper: 214 is 'done' and 114 is in progress and I probably can finish it today [19:06] ec2 secondary nics [19:06] I have a feeling that 211 ? [19:06] ec2 secondary ips I mean [19:06] oh right, 211 (pytest) 214 (sys_info in instance-data), and secondary ips (114) [19:07] heh, "old" [19:07] yeah should've done the secondary ips a looong time ago ... ahh well [19:07] lacking a clear answer here, I'd ask in #ubuntu-devel on , or read more on FFE w.r.t whether we can do a new-upstream-snapshot into focal or if we have to cherry pick and then cleanup when we do first SRU into focal after release