#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.2015-07-07-16.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 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
<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.2015-07-21-16.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 j5q85mmi6ujvjtii5s1n3li5io@group.calendar.google.com."
<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.2015-07-21-16.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 :)
