16:02 <stgraber> #startmeeting Ubuntu Technical Board
16:02 <meetingology> Meeting started Tue Jul 21 16:02:03 2015 UTC.  The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
16:02 <meetingology> 
16:02 <meetingology> Available commands: action commands idea info link nick
16:02 <stgraber> #topic Action review
16:02 <stgraber> slangasek: any progress with legal?
16:02 <slangasek> stgraber: have not yet referred it to them
16:02 <slangasek> (maybe you want to quote the action items in question?)
16:03 * stgraber slangasek to forward complaint to Canonical legal
16:03 <slangasek> :)
16:03 <stgraber> ok, so carrying that one forward again
16:03 <stgraber> #topic Scan the mailing list archive for anything we missed (standing item)
16:04 <stgraber> we've got a few requests for MREs but those require a single TB hack and discussoin appears to be ongoing.
16:04 <mdeslaur> I acked the oslo one this morning, and I'll add it to the wiki after the meeting
16:04 <stgraber> anyone feels like we should discuss any of those threads here?
16:05 <slangasek> stgraber: sorry, there were other action items from last meeting that I think we've skipped
16:05 <infinity> I'd take the silence as a no.
16:06 <stgraber> slangasek: ah? the wiki doesn't list any
16:06 * teward raises his hand
16:06 <slangasek> http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-07-07-16.01.html
16:06 <slangasek> (is the convention that the previous chair transcribes these into the agenda for the next meeting?)
16:06 <stgraber> yes
16:07 <slangasek> ok, sorry for missing that
16:07 <stgraber> #topic Action review
16:07 * stgraber slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases
16:07 <slangasek> not done, also carry over
16:08 * stgraber pitti to propose amendment to general SRU policy for new features in LTS
16:08 <stgraber> no pitti around and I don't believe I've seen a thread on that yet, so will carry over too
16:08 <infinity> Seems not done, unless he proposed it very quietly.
16:08 * stgraber all to respond to the Ubuntu Fan SRU proposal on list
16:08 <stgraber> so far all == pitti I believe, though he's been asking good questions :)
16:08 <infinity> pitti responded to the fan thing.  I recused myself, since I was involved in the implementation.
16:09 <infinity> But I'm happy with pitti's ACK.
16:10 <stgraber> ok. I'll keep the action around and will answer to the thread, hopefully some of the other members will too
16:10 <slangasek> I had intended to, but it's on the TODO pile in the corner
16:11 <stgraber> #topic Scan the mailing list archive for anything we missed (standing item)
16:11 <stgraber> so back to that, sounded like nobody at anything they wanted to bring here for discussion
16:11 * teward raises his hand
16:11 <stgraber> (waiting for wiki.ubuntu.com to log me in...)
16:11 <stgraber> teward: hi
16:12 <stgraber> teward: I'm assuming that's about nginx?
16:12 <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.
16:12 <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
16:13 <mdeslaur> teward: sorry, I didn't get a chance to look at it yet, but I will look at it this week
16:13 <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)
16:13 <teward> mdeslaur: no problem, thank you for letting me know.
16:14 <teward> I did however at least want to make sure it was on the radar.  :)
16:14 <mdeslaur> yes, it is
16:14 <teward> thank you.  that is all from me on it.  :)
16:15 <mdeslaur> I gather the others simply haven't had time to look it over either
16:15 <infinity> I've not given it a ton of thought yet, but it's in the back of my mind.
16:15 <stgraber> my feeling is that this doesn't really need TB input
16:16 <infinity> Well, it does if the ultimate plan results in a post-release update to a new version.
16:16 <teward> stgraber: the only reason I say otherwise is that Daviey of the Release Team suggested it shoudl be elevated to TB
16:16 <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.
16:16 <stgraber> that is, package the rc releases during the X cycle
16:16 <stgraber> then get a FFe if those do somehow include new features
16:17 <stgraber> and as soon as final is released, upload it either to the dev release (if not released yet) or as an SRU
16:17 <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
16:17 <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.
16:17 <teward> ^ that
16:17 <teward> (i was ninja'd)
16:18 <rbasak> It's not guaranteed to be bugfix only.
16:18 <rbasak> But we still think it's the best option available to us.
16:18 <stgraber> hmm, so they don't fork mainline to stable a bit ahead of the stable release?
16:18 <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
16:18 <teward> no pre-releases
16:19 <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)
16:19 <teward> that is, the tagged 1.9.x versions in the upstream repository.
16:19 <infinity> teward: Is there any guaranteed roadmap from upstream that 1.10 will come out when you think it will?
16:19 <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
16:20 <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?
16:20 <teward> infinity: only the assurances of our contact, the Senior Developer Advocate at nginx.  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
16:20 <teward> exactly *when* in april appears to be slightly variable
16:20 <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
16:21 <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
16:21 <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.
16:21 <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.
16:22 <stgraber> rbasak: well, you'll understand that I won't give you an exception for code that doesn't exist yet :)
16:22 <teward> infinity: that's the general idea, yes.
16:22 <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).
16:22 <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?
16:22 <rbasak> stgraber: we think that would be useless to Ubuntu nginx users
16:23 <mdeslaur> well, wily is only supported for 8 months anyway...
16:23 <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
16:23 <infinity> mdeslaur: Yes, but they don't want to have to revert from 1.9 to 1.8 between W and X.
16:23 <infinity> mdeslaur: Wily being 1.9 is fine, X being 1.9 isn't.
16:23 <rbasak> Right.
16:24 <rbasak> And X being 1.8 is maybe better, but still will probably be considered old and generally useless in X.
16:24 <mdeslaur> oh, sorry, april, got it now
16:24 <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".
16:24 <mdeslaur> as I said, I didn't have time to read over the proposal
16:24 <rbasak> So we'd rather ship 1.10 in X so that the nginx package is relevant to users during X's lifetime.
16:25 <teward> infinity: that echos my proposed course of action
16:25 <rbasak> (s/ship/bump post-release/ if you like)
16:26 <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.
16:26 <teward> s/1.10.x/1.9.x final/
16:26 <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
16:26 <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
16:27 <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.
16:27 <mdeslaur> as long as it's in the release notes, and happens before 16.04.1
16:27 <teward> infinity: Correct, that's the proposed course of action
16:27 <teward> infinity: although Debian tries to stay on top of 1.9.x when they do follow the mainline releases
16:27 <infinity> teward: Alright, then a +1 from me on that.
16:28 <rbasak> So you're proposing to effectively an FFe and a post-release SRU subject to these conditions?
16:28 <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.
16:29 <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.
16:29 <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?
16:30 <rbasak> (after X FFe I mean)
16:30 <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)
16:30 <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.
16:31 <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
16:31 <rbasak> OK, that's clear. Thanks.
16:31 <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".
16:32 <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
16:33 <teward> which can be used to determine if an FFe is needed or not there.
16:33 <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.
16:33 <teward> correct.
16:34 <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
16:34 <teward> (due to substantial changes or such)
16:34 <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?
16:36 <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.
16:36 <rbasak> (at which point you could nak if you see insanity)
16:36 <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?"
16:38 <infinity> Assuming the chair is still awake.
16:38 <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.
16:38 <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.
16:38 <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)
16:38 <stgraber> sorry, was typing :)
16:38 <infinity> +1
16:38 <meetingology> +1 received from infinity
16:38 <mdeslaur> +1
16:38 <meetingology> +1 received from mdeslaur
16:38 <stgraber> +1
16:38 <meetingology> +1 received from stgraber
16:39 <slangasek> +1
16:39 <meetingology> +1 received from slangasek
16:39 <infinity> I think the 1s have it.
16:40 <stgraber> yup
16:40 <stgraber> #endvote
16:40 <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.
16:40 <meetingology> Votes for:4 Votes against:0 Abstentions:0
16:40 <meetingology> Motion carried
16:40 <rbasak> Thanks!
16:40 <teward> Thank you very much for looking at this!
16:40 <stgraber> #topic Check up on community bugs (standing item)
16:40 <stgraber> nothing, as usual
16:40 <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?
16:41 <stgraber> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
16:41 <stgraber> that would be infinity
16:41 <infinity> Then kees, yes.
16:41 <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.
16:41 <stgraber> #topic AOB
16:42 <infinity> teward: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-07-21-16.02.log.txt
16:42 <rbasak> o/
16:42 <rbasak> I had one AOB
16:42 <teward> infinity: ack, thanks.
16:42 <infinity> Which is disturbingly up to date.  It must have just ran the job...
16:42 <teward> infinity: very possible :)
16:42 <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
16:42 <rbasak> (before the minutes are updated)
16:42 <rbasak> Would someone please add it?
16:43 <rbasak> (unless I'm missing something)
16:45 <infinity> rbasak: It does indeed seem to not be there anymore.  Weird.
16:45 <rbasak> I would have JFDI but I didn't want to presume your schedule. I _think_ it's every two weeks?
16:45 <slangasek> it is
16:46 <infinity> It is.  For now.  We've been discussing maybe changing that.
16:46 <rbasak> Then I'll JFDI if you like.
16:46 <rbasak> But please remember to change it if your schedule changes.
16:46 <infinity> Well, we already have a meeting.
16:46 <infinity> Since it notifies me every two weeks.
16:46 <infinity> We probably just need to invite the fridge.
16:46 <rbasak> OK, I'll leave it to you then :)
16:47 <infinity> Huh.  And the fridge *is* invited.  Even weirder.
16:47 <infinity> Should look into that, I guess.
16:48 <rbasak> "Under Add Guests, invite j5q85mmi6ujvjtii5s1n3li5io@group.calendar.google.com."
16:48 <rbasak> From
16:48 <rbasak> https://wiki.ubuntu.com/Fridge/Calendar
16:48 <infinity> Yeah, I know.  I'm in the same place. :P
16:48 <slangasek> maybe the fridge has a busy social life and has declined our invitation
16:48 <infinity> It did decline, actually.
16:48 <mdeslaur> we're not cool enough for the fridge
16:49 <rbasak> It is cool in the fridge. You just need to be let in :-)
16:51 <mdeslaur> rbasak: was that your AOB?
16:51 <rbasak> Yes
16:51 <mdeslaur> ok
16:52 <stgraber> ok, sounds like we're done then
16:52 <stgraber> #endmeeting