#ubuntu-meeting-2 2015-07-07 * slangasek waves <mdeslaur> hi! <pitti> \o <slangasek> #startmeeting <meetingology> Meeting started Tue Jul 7 16:01:19 2015 UTC. The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <slangasek> [TOPIC] Apologies <slangasek> no apologies sent on the list <slangasek> kees, infinity appear to be absent <slangasek> but we nevertheless have a quorum, so carrying on :) <slangasek> [TOPIC] Action review <slangasek> ACTION: slangasek to forward complaint to Canonical legal <slangasek> carried over, again <slangasek> again, if anyone felt strongly about stealing this from me I wouldn't stand in their way, otherwise I'll keep it on my todo <pitti> FTR, stgraber is on holidays? <stgraber> no I'm not :) <mdeslaur> he just wishes :) <stgraber> :) <slangasek> nope, we're all still working, no matter how much our brains are overheating in this weather ;) <slangasek> [TOPIC] Mailing list archive <slangasek> there was a mail from apw this morning, which I just saw in the queue and approved through <slangasek> I'm guessing most people haven't read it yet <pitti> ah, I already wondered <slangasek> Subject: Ubuntu Fan Updates for Trusty and Vivid <pitti> I quickly read through it, but I'm not entirely sure about the impact yet <mdeslaur> I skimmed it, but I'd have to look at the patch to form an opinion <slangasek> for those who don't know, Ubuntu Fan is a clever stateless network multiplexer <slangasek> it's a useful feature to have on cloud instances running containers <slangasek> apw had approached me and asked me if it was SRUable <pitti> it sounds similar to IPv4LL and NAT, and all the other crazy things people do to avoid IPv6 :) <slangasek> and I expressed concern that this doesn't really fit our existing SRU policy, so should be discussed at a higher level <pitti> but AFAIUI this is mostly a new feature, ignoring some undocumented preview that was already in the trusty kernel <slangasek> vivid kernel <pitti> i. e. the regression potential is that someone made use of that in trusty, and it's going to change/break? <pitti> ah <pitti> so for trusty this is entirely new <slangasek> yes, the risk of regression potential is fairly low because it's a new feature <stgraber> my main concern is the changes to iproute2 and other core bits to support the feature <mdeslaur> is this upstream yet? what are the odds that it gets changed in an incompatible way while going upstream? <slangasek> however, the SRU policy has always been rather clear that new features don't belong in SRUs - with the exception of hardware enablement <pitti> yeah, that's my main gripe with it -- there's no indication of whether this has ever been reviewed by kernel developers, or proposed for inclusion <slangasek> we've moved the line a few times wrt hardware enablement, to accomodate cloud substrate requirements <stgraber> so last I heard, it's not upstream and we're not actively pushing for it to be upstreamed in its current shape, it also uses kernel identifiers for the tunnel type which may potentially be used by another in-kernel tunneling technology at some point, causing a clash <slangasek> but I don't think I can justify this under the current SRU policy, so I think there's a higher-level policy discussion to be had rather than just making exceptions <pitti> (wrt. security/quality review, and general sanity) <pitti> so while from a regresssion potential POV this seems manageable (assuming that iproute2 only gets new features, and no changed behaviour) <stgraber> so basically from my point of view: 1) ubuntu-fan package itself is fine and safe 2) changes to iproute2 may be risky 3) in-kernel non-upstream tunnel technology when needing unique IDs for netlink is a risk too <pitti> it feels like exposing millions of LTS users with a brand new and largely unreviewed kernel feature that will be exposed to the network is a bit premature <slangasek> so, I'd appreciate it if we could separate our SRU team hats from our TB hats here, difficult as that is :) <pitti> sure; this is all TB anyway, as it's clearly outside of SRU policy <slangasek> when I asked apw to refer it to the TB, it wasn't because I wanted the TB to analyze the risks of this specific SRU <slangasek> but to discuss whether the SRU policy should, or should not, allow for updates such as this <stgraber> ah, simple answer then, it shouldn't <pitti> personally I would never like to give out a blanket permit for things like this <slangasek> pitti: well, I have the opposite response: that we shouldn't give /exceptions/ for things like this :) <pitti> even with this concrete case I have some serious concerns, I don't see how to allow even more general cases <stgraber> backporting of a new major feature into a LTS release is very clearly out of scope for the normal SRU process and as it's not something I want to see abused, I don't believe it makes sense to have the SRU policy allow this <pitti> slangasek: that'ss a good point from the POV that general written-down policy is better than arbitrary exceptions that are handed to whoever shouts the loudest <slangasek> if it's justifiable in the specific case (which it may not be), I think that we should address that in the SRU policy. The SRU policy currently says we don't allow new features in, this is a new feature: is the policy wrong, or is the SRU proposal one we should reject <slangasek> so I'd say that taking the pulse here suggests that we don't want this SRU <pitti> hm, so we could imagine how the fan proposal would have to look like in order for us to consider it acceptable <stgraber> do we really need to update the SRU policy to say that the TB can overule? to me it seems like its stating the obvious... <pitti> and then generalize that? <slangasek> shall we follow up on the mailing list? <slangasek> stgraber: uh? I'm in no way talking about codifying "the TB can overrule" <mdeslaur> There is a lot of potential for abuse in letting new features in. Is having the power to rule on new features something the SRU team in interested in? <slangasek> speaking only for myself as an SRU team member: no <pitti> with my former SRU hat on: I wouldn't be <slangasek> because having the power to rule on it means we'll be constantly asked to rule on it <stgraber> so my point of view, is keep the SRU policy as is, no new features and have the SRU team reject anything that's a new feature. None of that prevents escalation through the TB for a specific exception as seems to be the case here. <pitti> processing SRUs is enough work without having to argue about new features all the time <pitti> I'd actually be okay with new features in LTSes under reasonable circumstances; we do it all the time already, after all <pitti> (new landscape or maas versions, etc.) <slangasek> stgraber: I would not be happy with the TB ever signing off on a specific exception to the new feature rule without being able to articulate a general principle <pitti> but they should have a reasonably low potential for introducing new bugs and security holes, which this particular proposal totally fails at <pitti> right -- e. g. for the HW enablement we have a generic justification in the policy <pitti> so if/once we agree to this particular proposal, we could then generalize it and see on which grounds we accept it <slangasek> fwiw my risk analysis of this particular SRU differs from yours - it's already in the vivid kernel, the vivid kernel will land in trusty as part of the hwe process, new kernels have a huge attack surface anyway for security holes and we have a kernel update cadence to deal with that <stgraber> yeah, the kernel side isn't a big concern of mine because we don't force those on our existing users <slangasek> I also think the SRU process is adequate for dealing with the risks of regression, and doesn't need direct TB involvement <stgraber> iproute2 however is a bit more problematic <slangasek> anyway, so far I'm hearing a pretty firm "no" - so I think the next steps are to take that back to the mailing list? <pitti> well, we wouldn't push/force it into trusty unless we were planning to actually use that feature, no? <pitti> i. e. in some cloud workload via iproute2? <stgraber> well, the feature can be used by anyone, cloud or not, it just shows up as a bridge that you can use with docker, lxc, lxd, ... <pitti> right, the normal kernel backporting process kind of gets us that through the backdoor, but it would be inert without userspace changes <pitti> so it's much less adding the new kernel feature, but rather making use of that by our default tools <stgraber> right, you need the ubuntu-fan package and tools to talk to iproute2 to talk to the new kernel netlink interface <slangasek> but it's also not as if this is going to be activated on existing systems automatically; someone has to invoke it to make use of it <pitti> in general I don't want to respond to these kinds of requests with a plain "no" (as there's usually a good use case behind it), but more with a "how" <pitti> slangasek: it's not? that's not at all clear to me <stgraber> yeah, as I said, I'm not too concerned about the kernel side of it. What I'm concerned with is modifying iproute2 <stgraber> because if iproute2 breaks somehow, that means no network on the affected machine and that's kinda bad <mdeslaur> part of the issue here is this seems to be an ubuntu-specific feature <pitti> slangasek: it's very easy to accidentally or deliberately enable it on upgrades <slangasek> pitti: it certainly is not, it's a completely new bridge type <mdeslaur> it's not as if it's a backport of something present in a new version <slangasek> mdeslaur: it's a backport of something present in a new version of the package in Ubuntu. I'm not sure from a policy perspective (as opposed to a risk analysis perspective) that we should distinguish between Ubuntu-specific vs. not <pitti> right, "ubuntu specific" doesn't belong into SRU policy, that should be general development policy <pitti> (FWIW, I really don't like having this in vivid either) <mdeslaur> slangasek: policy no, but it certainly has an impact on the risk. Even more so if there actually are plans to get it upstream and that turns into a compatibility nightmare for users. <pitti> so assuming it *was* a properly reviewed feature in vivid's kernel, I wouldn't have a problem with letting this migrate to trusty as well via the normal backport process <pitti> the "change userspace to make use of it" is what I'd like to understand more, as right now it sounds awfully dangerous <pitti> so the "how to make this palatable" would include an upstream review, plus a more detailled description of the current and planned userspace changes to iproute and other tools, and a regression potential analysis <pitti> all of which is really unrelated to SRUing this to trusty, but should retroactively be done for vivid too <slangasek> all of that still doesn't pass the SRU policy as it stands, and only supports making an exception? <slangasek> I'm against making an exception <pitti> as for the SRU policy, I think we can make an amendment for backporting features from stable releases to LTSes which have a negligible regression potential <pitti> it shoudl still be ack'ed individually IMHO, but it would be a guideline what the TB would look at <pitti> (TBH I have a bigger problem with the feature itself than with backporting it) <slangasek> ok; so you think that at least potentially this is something that we would want codified in the SRU policy as allowable <pitti> yes, I do <mdeslaur> pitti: acked by who, the SRU team or the tech board? <pitti> pitti | hm, so we could imagine how the fan proposal would have to look like in order for us to consider it acceptable <pitti> pitti | and then generalize that? <slangasek> I agree, though I'm not yet sure what shape it should take <pitti> mdeslaur: my feeling is "TB" at least initially <mdeslaur> ok <slangasek> but I think we're racking up exceptions at this point (maas, juju, proposal for fan) and we should consider whether the current SRU rules are still meeting their purpose <pitti> this shouldn't be a "toss over the fence" kind of thing, but similar to preliminary MREs <pitti> slangasek: right, that's a good point; now that we do have a lot of MREs we have some experience when we allowed them <slangasek> not just MREs :) <pitti> and most of the time the "interview" looked fairly similar: automatic/manual test plans and QA procedures, how to ensure that upgrades don't break, regression potential analysis <slangasek> [ACTION] slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases <meetingology> ACTION: slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases <pitti> slangasek: juju is on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions <slangasek> pitti: yes, but it's not actually an MRE so I'm going to move it :) <pitti> maas was proposed, but never got signed off because the interview wasn't finished <pitti> slangasek: ack <pitti> slangasek: I'm happy to look at our existing MacroReleaseExceptions and come up with a proposal for a policy amendment for next time <slangasek> so - next steps? should we evolve this on the mailing list? <pitti> as I usually responded to the bulk of MRE requests on the ML anyway <pitti> I think there's two steps: <pitti> 1) amend the policy for new features in LTS (as that's clearly a direction we've gone in in the past years) <pitti> 2) respond to that concrete case with our gripes and request for more information about them <slangasek> pitti: do you want to drive #1? <pitti> slangasek: yes <mdeslaur> pitti: that sounds reasonable <slangasek> [ACTION] pitti to propose amendment to general SRU policy for new features in LTS <meetingology> ACTION: pitti to propose amendment to general SRU policy for new features in LTS <slangasek> [ACTION] all to respond to the Ubuntu Fan SRU proposal on list <meetingology> ACTION: all to respond to the Ubuntu Fan SRU proposal on list <slangasek> [TOPIC] community bugs <slangasek> https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard <slangasek> empty <slangasek> [TOPIC] Select a chair for the next meeting <slangasek> I believe that's stgraber, with infinity as backup, yes? <stgraber> yep <slangasek> [INFO] Next meeting 2015-07-21, 17:00 London time. Chair: stgraber (next: infinity) <slangasek> anything else that I've missed? <pitti> nice to have a "real" meeting for a change :) <mdeslaur> hehe, yes :) <pitti> nothing else from me <slangasek> :) <slangasek> #endmeeting <meetingology> Meeting ended Tue Jul 7 16:49:58 2015 UTC. <meetingology> Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.6014050377.01.moin.txt <slangasek> thanks, all! <mdeslaur> thanks slangasek, thanks all <pitti> thanks everyone <stgraber> thanks <pitti> et bonne nuit ! <stgraber> :) #ubuntu-meeting-2 2015-07-21 <mdeslaur> o/ * slangasek waves <slangasek> stgraber: I believe you're on point? * teward waves and then silently sits in the corner <infinity> o/ * stgraber waves <stgraber> #startmeeting Ubuntu Technical Board <meetingology> Meeting started Tue Jul 21 16:02:03 2015 UTC. The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <stgraber> #topic Action review <stgraber> slangasek: any progress with legal? <slangasek> stgraber: have not yet referred it to them <slangasek> (maybe you want to quote the action items in question?) <stgraber> ACTION: slangasek to forward complaint to Canonical legal <slangasek> :) <stgraber> ok, so carrying that one forward again <stgraber> #topic Scan the mailing list archive for anything we missed (standing item) <stgraber> we've got a few requests for MREs but those require a single TB hack and discussoin appears to be ongoing. <mdeslaur> I acked the oslo one this morning, and I'll add it to the wiki after the meeting <stgraber> anyone feels like we should discuss any of those threads here? <slangasek> stgraber: sorry, there were other action items from last meeting that I think we've skipped <infinity> I'd take the silence as a no. <stgraber> slangasek: ah? the wiki doesn't list any * teward raises his hand <slangasek> http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.6014050377.01.html <slangasek> (is the convention that the previous chair transcribes these into the agenda for the next meeting?) <stgraber> yes <slangasek> ok, sorry for missing that <stgraber> #topic Action review <stgraber> ACTION: slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases <slangasek> not done, also carry over <stgraber> ACTION: pitti to propose amendment to general SRU policy for new features in LTS <stgraber> no pitti around and I don't believe I've seen a thread on that yet, so will carry over too <infinity> Seems not done, unless he proposed it very quietly. <stgraber> ACTION: all to respond to the Ubuntu Fan SRU proposal on list <stgraber> so far all == pitti I believe, though he's been asking good questions :) <infinity> pitti responded to the fan thing. I recused myself, since I was involved in the implementation. <infinity> But I'm happy with pitti's ACK. <stgraber> ok. I'll keep the action around and will answer to the thread, hopefully some of the other members will too <slangasek> I had intended to, but it's on the TODO pile in the corner <stgraber> #topic Scan the mailing list archive for anything we missed (standing item) <stgraber> so back to that, sounded like nobody at anything they wanted to bring here for discussion * teward raises his hand <stgraber> (waiting for wiki.ubuntu.com to log me in...) <stgraber> teward: hi <stgraber> teward: I'm assuming that's about nginx? <teward> stgraber: hello, and greetings to the Ubuntu Technical Board. While the silence to your inquiry to things to be brought up for discussion will stand, and I will not bother the TB for a decision today, I'd like to bring into view the request I sent to the mailing list with regards to NGINX for X-series. <teward> stgraber: correct, and the only reason I raised my hand is to say that while a decision is not needed today, it is needed soon, as the course of action decision does impact Wily to a point <mdeslaur> teward: sorry, I didn't get a chance to look at it yet, but I will look at it this week <teward> (as part of the nginx message requests a general opinion with regards to the proposed course of action for both X-series and Wily) <teward> mdeslaur: no problem, thank you for letting me know. <teward> I did however at least want to make sure it was on the radar. :) <mdeslaur> yes, it is <teward> thank you. that is all from me on it. :) <mdeslaur> I gather the others simply haven't had time to look it over either <infinity> I've not given it a ton of thought yet, but it's in the back of my mind. <stgraber> my feeling is that this doesn't really need TB input <infinity> Well, it does if the ultimate plan results in a post-release update to a new version. <teward> stgraber: the only reason I say otherwise is that Daviey of the Release Team suggested it shoudl be elevated to TB <stgraber> what version to get into wily as we're not in any kind of freeze is basically up to the server team, if the intend is to get the stable for next release, then doing the same thing as openstack would be appropriate. <stgraber> that is, package the rc releases during the X cycle <stgraber> then get a FFe if those do somehow include new features <stgraber> and as soon as final is released, upload it either to the dev release (if not released yet) or as an SRU <stgraber> since going from rc to final isn't an actual major version bump and is supposed to be bugfix only, the existing process does cover that nicely <rbasak> The difference is that upstream doesn't really do the same sort of RC as openstack. If you consider their "mainline" to be the RC for their "stable", which is what we're doing, then there's still no upstream "feature freeze" between the two. <teward> ^ that <teward> (i was ninja'd) <rbasak> It's not guaranteed to be bugfix only. <rbasak> But we still think it's the best option available to us. <stgraber> hmm, so they don't fork mainline to stable a bit ahead of the stable release? <teward> stgraber: no, they do not, their 1.10.x stable release will be cut from the final state of 1.9.x at cut time <teward> no pre-releases <teward> (as 1.9.x versions in mainline are considered stable enough for production use, they don't have a pre-1.10.x release/cut) <teward> that is, the tagged 1.9.x versions in the upstream repository. <infinity> teward: Is there any guaranteed roadmap from upstream that 1.10 will come out when you think it will? <stgraber> ok, so yeah, consider 1.9.x as the rc then, if you keep it updated regularly, the delta at the end should be minimal and may not even need a FFe, if there are new features then a FFe would be needed from the release team <rbasak> stgraber: so even if the final 1.10 arrives post-release, you still consider a release team FFe acceptable for a subsequent 1.10 SRU? <teward> infinity: only the assurances of our contact, the Senior Developer ramirezanna@example.org. A better roadmap for 1.10.x release date will likely be available closer to the end of this year, however they always cut stable from mainline in April <teward> exactly *when* in april appears to be slightly variable <stgraber> if the final 1.10 is tagged after X releases and the delta between the 1.9.x shipped in X and the upstream 1.10 does contain new features, then the SRU team will likely ask you to come to the TB <teward> stgraber: given that it's possible it will be that way, as the actual cut date for 1.10.x is not yet in stone, that's probably why Daviey suggested we elevate to the TB via a parallel discussion thread <rbasak> stgraber: that's my understanding, and that's what we'd like to have an exception for. We want a decision to be made now, since otherwise we don't think it makes sense to move to 1.9 in Wily now. <infinity> Given when we intend to release 16.04, the odds of 1.9.x in mid-April and 1.10 in late April being much different seem slim. <stgraber> rbasak: well, you'll understand that I won't give you an exception for code that doesn't exist yet :) <teward> infinity: that's the general idea, yes. <rbasak> stgraber: if an FFe or SRU were denied in the future, we'd be stuck shipping a dead and upstream unsupported 1.9 (or 1.8). <infinity> teward: Have you been involved in previous stable releases upstream? Do you know how much junk goes into mainline while they're winding down to a release? <rbasak> stgraber: we think that would be useless to Ubuntu nginx users <mdeslaur> well, wily is only supported for 8 months anyway... <teward> infinity: I have not been involved upstream, however judging from the traffic on the devel list and commits at the end of 1.7.x before the 1.8.x cut it was mostly bugfixes between the last 1.7.x release and the first 1.8.x release <infinity> mdeslaur: Yes, but they don't want to have to revert from 1.9 to 1.8 between W and X. <infinity> mdeslaur: Wily being 1.9 is fine, X being 1.9 isn't. <rbasak> Right. <rbasak> And X being 1.8 is maybe better, but still will probably be considered old and generally useless in X. <mdeslaur> oh, sorry, april, got it now <infinity> teward: Right, if that's their usual MO, sort of a soft freeze while attempting to cut a stable, then I think I'm okay with saying "yes, ship 1.9 and push 1.10 as soon as it's ready", but with a caveat of "please keep 1.9 as up to date as reasonable during the last couple of months of the cycle, so the final delta is tiny and reviewable". <mdeslaur> as I said, I didn't have time to read over the proposal <rbasak> So we'd rather ship 1.10 in X so that the nginx package is relevant to users during X's lifetime. <teward> infinity: that echos my proposed course of action <rbasak> (s/ship/bump post-release/ if you like) <teward> infinity: which is assuming the TB accepts the course of action, merge 1.9.x from Debian throughout Wily, and do the same through X, mirroring Debian and likely some manual packaging if Debian has any freezes in between now and 1.10.x. <teward> s/1.10.x/1.9.x final/ <teward> and then depending on the 1.10.x cut date, it either gets in pre-X release or post-X release as rbasak has said <mdeslaur> I think getting in the latest 1.9.x versions and then updating to 1.10.x post-release sounds like the sane thing to do for an LTS <infinity> teward: Unless the Debian maintainers upload a LOT, I'd take that one step further and say you want to keep uploading 1.9 snapshots after FF to make sure all the upstream bits are being tested before release and, again, to keep that final 1.10 delta low. <mdeslaur> as long as it's in the release notes, and happens before 16.04.1 <teward> infinity: Correct, that's the proposed course of action <teward> infinity: although Debian tries to stay on top of 1.9.x when they do follow the mainline releases <infinity> teward: Alright, then a +1 from me on that. <rbasak> So you're proposing to effectively an FFe and a post-release SRU subject to these conditions? <infinity> rbasak: Yeah. I mean, as stgraber says, it's hard to decide on code that doesn't exist yet, but I also get why you need to plan this so far in advance. <infinity> rbasak: So, I'd say "yeah, this sounds sane", but if features land post-FF that do look super scary, we're going to want solid test plans other than "yeah, it built" to make sure this won't bite us. <rbasak> infinity: I just want to clarify what action to take when we're ready to upload. Just upload if it's sane (including features after FFe), or get/expect review from release team or TB before upload? <rbasak> (after X FFe I mean) <teward> infinity: a decent gauge would be to track any bugs/issues that come up on the Mainline PPA, as I know people use that, and that's already keeping up to date as possible with nginx upstream releases (give or take a week right now due to some undue stress of last week preventing me uploading there) <infinity> rbasak: I think if it warrants an FFe (which isn't "new version" as people think, but "new features" or, "complete rewrites of existing features"), then file an FFe, but refer back to this discussion/decision. <stgraber> when you get to FF, get a FFe for the next upstream snapshots including 1.10. If 1.10 is tagged before release, yay, if not, then you'll need a chat with the SRU team <rbasak> OK, that's clear. Thanks. <infinity> rbasak: The TB certainly has the power here to pre-approve, but I'd rather do it conditionally on the "well, if it needs an FFe, that means you need to prove it works". <teward> I'll keep an eye on the changelogs as they come out as well, nginx is usually very adamant on identifying what's a bugfix or a feature change, etc. on the changelogs <teward> which can be used to determine if an FFe is needed or not there. <infinity> teward: Keep an eye on diff size. If a new upload has a 500k diff (that isn't all in testsuite code), there's a fair chance that even if there wasn't a new "feature", someone went and rewrote a subsystem in the name of a bugfix, and you want to pay special attention to what that might have broken and test it. <teward> correct. <teward> I usually have to track that anyways, upstream changes have sometimes prompted news entries in Debian which in turn require me to make a note about that, usually on my blog, cross-linked over my twitter <teward> (due to substantial changes or such) <infinity> Alright. I feel like, despite this being a thing one of us could JFDI a decision on, perhaps this warrants a vote for peace of mind for the server team? <rbasak> Yes please. It sounds like you've basically approved our plan but want a manual release team review step on FFe upload and SRU team review step on SRU upload. <rbasak> (at which point you could nak if you see insanity) <infinity> stgraber: Something like "Pre-approve potential FFe and one-time (possible) post-release version bump exception for nginx 1.9/1.10 in 16.04, conditional on acceptable review and testing being done?" <infinity> Assuming the chair is still awake. <stgraber> #vote Approve plan to go with nginx 1.10 in 16.04 with final upload potentially post-release. Pre-approve FFes required to keep 16.04 close to final 1.10 pre-release and one-time version bump post-release if needed. Conditional on standard review and testing. <meetingology> Please vote on: Approve plan to go with nginx 1.10 in 16.04 with final upload potentially post-release. Pre-approve FFes required to keep 16.04 close to final 1.10 pre-release and one-time version bump post-release if needed. Conditional on standard review and testing. <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) <stgraber> sorry, was typing :) <infinity> +1 <meetingology> +1 received from infinity <mdeslaur> +1 <meetingology> +1 received from mdeslaur <stgraber> +1 <meetingology> +1 received from stgraber <slangasek> +1 <meetingology> +1 received from slangasek <infinity> I think the 1s have it. <stgraber> yup <stgraber> #endvote <meetingology> Voting ended on: Approve plan to go with nginx 1.10 in 16.04 with final upload potentially post-release. Pre-approve FFes required to keep 16.04 close to final 1.10 pre-release and one-time version bump post-release if needed. Conditional on standard review and testing. <meetingology> Votes for:4 Votes against:0 Abstentions:0 <meetingology> Motion carried <rbasak> Thanks! <teward> Thank you very much for looking at this! <stgraber> #topic Check up on community bugs (standing item) <stgraber> nothing, as usual <infinity> teward: In the name of us all being super lazy^wbusy people, care to follow up to your own thread with a pointer to the IRC log, so we can easily refer back later? <stgraber> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) <stgraber> that would be infinity <infinity> Then kees, yes. <teward> infinity: i will be glad to follow up to that thread and point to the IRC logs here for the vote on this, yes. <stgraber> #topic AOB <infinity> teward: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.6014050377.02.log.txt <rbasak> o/ <rbasak> I had one AOB <teward> infinity: ack, thanks. <infinity> Which is disturbingly up to date. It must have just ran the job... <teward> infinity: very possible :) <rbasak> I noted that fridge.ubuntu.com doesn't list the TB meeting any more, so I find it quite hard to find the schedule <rbasak> (before the minutes are updated) <rbasak> Would someone please add it? <rbasak> (unless I'm missing something) <infinity> rbasak: It does indeed seem to not be there anymore. Weird. <rbasak> I would have JFDI but I didn't want to presume your schedule. I _think_ it's every two weeks? <slangasek> it is <infinity> It is. For now. We've been discussing maybe changing that. <rbasak> Then I'll JFDI if you like. <rbasak> But please remember to change it if your schedule changes. <infinity> Well, we already have a meeting. <infinity> Since it notifies me every two weeks. <infinity> We probably just need to invite the fridge. <rbasak> OK, I'll leave it to you then :) <infinity> Huh. And the fridge *is* invited. Even weirder. <infinity> Should look into that, I guess. <rbasak> "Under Add Guests, invite ramirezanna@example.org." <rbasak> From <rbasak> https://wiki.ubuntu.com/Fridge/Calendar <infinity> Yeah, I know. I'm in the same place. :P <slangasek> maybe the fridge has a busy social life and has declined our invitation <infinity> It did decline, actually. <mdeslaur> we're not cool enough for the fridge <rbasak> It is cool in the fridge. You just need to be let in :-) <mdeslaur> rbasak: was that your AOB? <rbasak> Yes <mdeslaur> ok <stgraber> ok, sounds like we're done then <stgraber> #endmeeting <meetingology> Meeting ended Tue Jul 21 16:52:07 2015 UTC. <meetingology> Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.6014050377.02.moin.txt <mdeslaur> thanks everyone! <rbasak> Thanks all! <teward> infinity: i'd like you to spot-check my wording, if you wouldn't mind, before I send this: http://paste.ubuntu.com/11915402/ I'll add in the link as well, but before I send i'd like a sanity check <rbasak> teward: link to IRC logs please <rbasak> teward: otherwise lgtm <teward> rbasak: just said i'll ad it * teward points at "I'll add in the link as well" <slangasek> thanks, all <infinity> teward: WFM. <rbasak> Oh, sorry. <infinity> rbasak: Fridge calendar happier now. <rbasak> \o/ <rbasak> Thanks! <teward> infinity: rbasak: sending now, with the logs, and also the link to the meeting minutes that meetingology created so people don't absolutely have to go digging to find the vote :) <teward> thanks again to all of the TB :) #ubuntu-meeting-2 2016-07-05 <mdeslaur> meeting? <mdeslaur> hrm, seems everyone ramirezanna@example.org... * mdeslaur declares meeting cancelled and goes to lunch. <kees> \o/ #ubuntu-meeting-2 2016-07-19 * slangasek waves <mdeslaur> \o <slangasek> wiki page says infinity or kees is chairing <slangasek> infinity is at a sprint right now so I'm not sure he'll make it <bregma> kgunn is at the same sprint (I believe) so I'll be substituting for him today <mdeslaur> hi bregma <kees> \o <kees> so I'm chairing? <mdeslaur> kees: congrats <kees> #startmeeting <meetingology> Meeting started Tue Jul 19 16:04:16 2016 UTC. The chair is kees. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <kees> #topic action review <kees> #meetingtopic action review <kees> uhm... wtf <kees> [topic] hello bot <kees> so, infinity is out, so I guess I'll skip his actions? <mdeslaur> sure <kees> "mdeslaur to look into flavour CVE tracking" <mdeslaur> you can carry mine forward too, I haven't had time to work on that yet <kees> done! <kees> #topic unity 8 PPA <bregma> this is regarding https://bugs.launchpad.net/unity8-desktop-session/+bug/1585362 <bregma> we require either formal TB approval or rejection <slangasek> [LINK] https://bugs.launchpad.net/unity8-desktop-session/+bug/1585362 <slangasek> right <slangasek> I would've liked to get the discussion on this one started on the mailing list, given that I'm not sure we'll finish in a live TB meeting, but ENOTIME :/ <slangasek> so this kind of question has come up in various forms over time <kees> uuhhh... adds a PPA to to sources by default? no. put in -proposed? I don't understand the problem? <mdeslaur> The list of packages in the PPA is troubling, since it contains more than just unity 8 stuff, like a newer network-manager, etc. <mdeslaur> I don't think that's appropriate <slangasek> kees: the problem is that this is the ppa that contains the various packages which have been forked for the phone product and have not been SRUed into the release <bregma> the over all goal is to make it as simple and easy as possible for people to test the Unity 8 desktop on 16.04 without a two-step (and hence error-prone) process <kees> the language in this bug doesn't explain anything to me. is this for _testing_, or is this for _default_? <kees> if it's for testing, why is the TB needed? <mdeslaur> the issue is that installing that PPA is likely to break people's systems... <slangasek> this is for opt-in to the unity8 stack, for end users <slangasek> the current unity8 stack, in the ppa, which is not the same as the one in xenial <bregma> it's definitely not for default 16.06, not for default 16.10 which should have all the required packages in main by then <slangasek> because the phone team's process has very good CI to prevent regressions for their stack, but having to regression-test it in Ubuntu for all other use cases would slow down development to a molasses pace - so they generally haven't been SRUing <kees> I still do not understand the problem: adding a PPA is already trivial for end users to do. what is the issue that needs TB approval? <slangasek> kees: they wanted auto-ppa enablement on package install <kees> no. <kees> :P <mdeslaur> the approval is for the ppa to be automatically enabled with a xenial update of one of the unity 8 packages <kees> that's not how Ubuntu does things. :) <kees> if someone wants to test new unity8, they can run the ppa adding tool. it's a single command line... ? <kees> it seems like if someone can't do that, they shouldn't be testing things that will break their system. <mdeslaur> I'm not sure the simple question that gets asked on that package upgrade is enough to inform users of what enabling that ppa entails <bregma> users, eben the technically inclined, have a history of clicking on shiny things without reading the documentation first, a one-click install is less error-prone <mdeslaur> for example, will the new network-manager in there break their kde or gnome desktop? <slangasek> it's not really one commandline, because it's "apt-add-repository <magicstring>; confirm scary commandline prompt; apt-get update; apt-get dist-upgrade" <kees> and if that's too scary, you want someone to test a system-breaking ppa that can't handle said scariness? <slangasek> I personally find the apt-add-repository interface much less simple than I think it ought to be :) <kees> how about adding "update and dist-upgrade" to the apt-add-repository script? <slangasek> +1 from me on that, but I'm not sure if that addresses kgunn/bregma's issue <mdeslaur> how about simply adding a "enable-unity8-ppa" tool that prints an appropriate warning? <kees> mdeslaur: is that any better than apt-add-repository? <mdeslaur> if the objection is that apt-add-repository is not discoverable and has scary messages, then a more specialized tool would fix that <mdeslaur> bregma: what testing is performed in that PPA to make sure it doesn't break kde or gnome desktops? <slangasek> should we discuss the reasons why the packages in question are in this extra ppa in the first place? <bregma> mdeslaur, at the moment there is mostly informal testing of the PPA on desktop, we're working on mringing that up to par <slangasek> mdeslaur: the ppa is primarily the phone ppa; so the baseline testing for GNOME/KDE compatibility is 0 <bregma> we are working on MIR for these packages for 16.10, so this should not be a problem going forward <mdeslaur> right, so that would be my first objection...someone runs gnome, installs the unity 8 desktop to try it out, and it breaks their main gnome desktop <slangasek> even if bregma's team made that part of their test plan for their updates, there are bound to be other updates landing there to fix phone issues that may not have been tested by them on the desktop <slangasek> and might get pulled in if the ppa is enabled <bregma> yes <slangasek> bregma: sorry, I don't understand how the MIR changes things <mdeslaur> bregma: how is a MIR going to fix the issue of rapid releases? <bregma> they're going either have to branch their upstream projects like everyone else does so they can support Ubuntu as well as the phone <slangasek> fwiw I have been of the view for some time (with my SRU team hat on) that I would like to see more of the packages that land in the overlay ppa SRUed into Ubuntu <slangasek> the SRU process adds calendar time, and should not block the phone team from getting updates done <bregma> agreed, and that's part of how I see convergence working <slangasek> but in general, since these packages also all exist in the main Ubuntu archive and are considered abandonware / not fit for purpose in those versions, I think ideally they would get SRUed and not just published to the overlay <bregma> our goal is to see Unity 8 in the ISO as an alternative session for 16.10 (hence the MIRs), which would require branching upstream so a rapid cadence contines in the PPA but changes get SRUd into the Ubuntu archives <slangasek> however I know that getting SRUs done for each package is going to increase the load on the development team; so is that feasible at this stage? <mdeslaur> +1 <slangasek> bregma: ok. so you're saying that's the roadmap for 16.10 forward, there would be landings in both the overlay ppa and as SRUs, but that's not on the roadmap for 16.04? <bregma> well, 16.04 has already been released, so I would see that as being a technical challenge <slangasek> bregma: from my POV, it seems technically possible to start SRUing packages onto 16.04 today, forking off of the existing packages in the overlay and putting them through the SRU process <bregma> slangasek, yes, it's possible although they would remain in universe of course <slangasek> i.e. I don't see any difference, technically, between doing this now for 16.04 vs. doing this for 16.10 <bregma> we have just not considered doing that <slangasek> ok <slangasek> if you went that route, you wouldn't need the TB's blessing for anything; you'd be using the standard SRU process <slangasek> and it means the updates would get verified to ensure they don't regress other stacks in Ubuntu, which is a nice assurance <slangasek> but it also obviously means more team for your work to prep and validate those SRUs - no shortcuts there <slangasek> more team for your work? hello brain <bregma> that work will need to be done for 16.10 and onward, it's a matter of accelerating the plan <bregma> but given that adding the PPA could possibly break other desktops resulting in increased support workload, it's a worthwhile consideration <bregma> I will take the suggestion back to the decision makers and defer the question of adding the PPA with the package install until that is resolved <slangasek> ok <kees> alrighty. settled for now, it seems... <slangasek> btw I do remember internal discussion earlier about having a separate ppa for just the converged stack, with different requirements for contents <slangasek> should I assume the consensus in the TB is that auto-enabling this on package install would also be unacceptable, regardless of the criteria for the ppa? <mdeslaur> I would vote -1 on auto-enabling it, yes <slangasek> ok <slangasek> bregma: you have enough guidance then? :) <slangasek> (should we have a formal vote on the auto-enable question, for the record?) <bregma> one question: would this be a "standing SRU" or separate SRUs required for each update? <slangasek> bregma: for packages that Canonical is the upstream for within that stack, I would prefer we figure out a standing SRU policy for them that doesn't require writing per-update test cases <slangasek> when it touches other packages in the archive, those would need to be more ad hoc <bregma> OK <bregma> I think I have enough guidance on this, then <bregma> I would like a formal vote on the matter to take back to my masters <kees> #topic mailing list <kees> erf, vote on which piece? <mdeslaur> auto-enabling of the PPA <slangasek> I'd posit [VOTE] decline to grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install; recommend convergence team work with SRU team to include their changes in the main Ubuntu archive" <kees> so, "should package installs be allowed to auto-enable third-party PPAs?" is that the right language? <slangasek> maybe with fewer words <kees> I don't like the inverted question, let's try this... <kees> #vote grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install? <meetingology> Please vote on: grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install? <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) <kees> -1 <meetingology> -1 received from kees <mdeslaur> -1 <meetingology> -1 received from mdeslaur <slangasek> -1 <meetingology> -1 received from slangasek <kees> #endvote <meetingology> Voting ended on: grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install? <meetingology> Votes for:0 Votes against:3 Abstentions:0 <meetingology> Motion denied <bregma> thank you for your time <slangasek> bregma: thank you! <kees> and, for the second part, there's not really a vote needed: the recommendation would be to work with the SRU team. <slangasek> ok <slangasek> mailing list? :) <kees> right. <kees> so, nothing new there (this topic was the only one I saw) <kees> #topic bugs <kees> nothing new <kees> #topic aob <kees> anything? <slangasek> not here <mdeslaur> nope <kees> #topic chair selection <kees> looks like mdeslaur with slangasek as backup? <slangasek> or would it be infinity with mdeslaur backup? <slangasek> (doesn't matter :) <kees> hm, yeah <kees> okay, infinity with mdeslaur <mdeslaur> ack <kees> okay, thanks everyone! <kees> #endmeeting <meetingology> Meeting ended Tue Jul 19 16:51:05 2016 UTC. <meetingology> Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.6014050377.04.moin.txt <mdeslaur> thanks bregma! <mdeslaur> thanks everyone #ubuntu-meeting-2 2017-07-04 <mdeslaur> \o <mdeslaur> hrm, no stgraber, no infinity <mdeslaur> others are busy blowing fingers off * mdeslaur declares meeting cancelled in 3... <mdeslaur> 2... <mdeslaur> 1... <mdeslaur> cancelled. #ubuntu-meeting-2 2017-07-18 * slangasek waves <mdeslaur> \o <infinity> o/ <slangasek> infinity: hi, not sure stgraber is showing, you may be in charge :) <infinity> Well poop. <kees> o/ <mdeslaur> hi kees * stgraber waves <mdeslaur> hi stgraber <kees> hola <mdeslaur> infinity: lucky :) <infinity> I jabbed him in his tiny ribs. <stgraber> #startmeeting TB meeting <meetingology> Meeting started Tue Jul 18 16:05:27 2017 UTC. The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <mdeslaur> hehe <stgraber> #topic Actions <stgraber> infinity: made any progress on yours? <stgraber> ACTION: infinity to ask maas team to prepare SRU exception policy Ã la CurtinUpdates <stgraber> ACTION: infinity to play with seed/maint-check changes on dogfood to build a new xenial release pocket for support length auditing (ETA: 16.04.3 release) <infinity> https://wiki.ubuntu.com/MAASUpdates is a thing now. Last roaksoax said, it "wasn't done yet", I'll have to catch up with him to see if it's ready for review. <infinity> And no movement on the maint-check thing. <slangasek> agreed wrt it not being done, but fwiw it was useful to me when processing the most recent SRU, so that's progress <slangasek> (wrt https://wiki.ubuntu.com/MAASUpdates) <infinity> Maybe I should I make a card for it, since that's the hip new thing to do. <stgraber> being agile now? :) <infinity> As little as I can manage. <stgraber> ACTION: slangasek to investigate getting tagged ubuntu-community bugs automatically forwarded to technical-board, and if not feasible, fall back to DMB sending signed emails to list for ACL requests <stgraber> ACTION: slangasek to follow up to snapd-glib SRU exception request <stgraber> slangasek: how about those two? <slangasek> the first is carry-over <slangasek> the second was done on the mailing list <stgraber> ok, updated the wiki <stgraber> #topic Mailing-list stuff <stgraber> not seeing anything relevant for this meeting, other than the aforementioned snapd-glib thread <stgraber> #topic LP bugs <stgraber> https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard is empty <stgraber> #topic Next chair <stgraber> infinity, kees as backup <stgraber> #topic AOB <stgraber> anyone got anything? <mdeslaur> I don't <infinity> I'm OBless. <slangasek> I'm good <stgraber> #endmeeting <meetingology> Meeting ended Tue Jul 18 16:13:12 2017 UTC. <meetingology> Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2017/ubuntu-meeting-2.6014050377.05.moin.txt <stgraber> thank you very much for attending :) <slangasek> thanks! <mdeslaur> thanks stgraber, thanks everyone <kees> thanks! #ubuntu-meeting-2 2018-07-03 * slangasek waves <mdeslaur> hi <slangasek> stgraber as chair? #ubuntu-meeting-2 2018-07-31 * slangasek waves <mdeslaur> \o <slangasek> do we have a chair and is it me? <slangasek> https://wiki.ubuntu.com/TechnicalBoardAgenda hasn't been updated since June; which means stgraber is the chair <stgraber> do we have anything to meet about? <stgraber> #startmeeting <meetingology> Meeting started Tue Jul 31 19:07:14 2018 UTC. The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology. <meetingology> Available commands: action commands idea info link nick <stgraber> #topic Action review <stgraber> ACTION: Wimpress To follow-up on-list with design review to address MATE Boutique security/consent concerns. <mdeslaur> I don't see that on the list <stgraber> yeah, neither do I <stgraber> ACTION: infinity to ask maas team to prepare SRU exception policy Ã la CurtinUpdates (see https://wiki.ubuntu.com/MAASUpdates) <stgraber> I'm not seeing anything * stgraber waits for the wiki to load to see the rest of the agenda <stgraber> ACTION: slangasek and mdeslaur to more clearly define third party seeded snap security policy <mdeslaur> stgraber: you should upgrade to a v.92 modem <slangasek> mdeslaur: I guess we should block some time to do something about that? <mdeslaur> yeah, perhaps wait until the new tech board even? <stgraber> mdeslaur: pretty sure my end is fine, need to get IS to budget a faster modem for that server :) <slangasek> mdeslaur: well, it needs doing and the TB elections don't seem to be making any more forward progress than our action items <mdeslaur> slangasek: ok, let me catch up on the past discussions and I'll get back to you <stgraber> ACTION: tsimonq2 to email proposed policy for flavor-notification of daemons being added to all flavors (e.g. snapd into desktop-common) <tsimonq2> Yup, done/. <tsimonq2> s/\/// <tsimonq2> Just needs ratification, I believe. <slangasek> yeah, I was going to re-review it but I think it's more or less solid now <stgraber> sounds good <stgraber> #topic Review of the seeded snaps policy <tsimonq2> slangasek: I reworked it a little bit after your feedback. <stgraber> slangasek: that one's yours I believe <slangasek> hmm, I've lost context and don't remember why this was
{'channel': 'ubuntu-meeting-2', 'month': 7}