=== racedo` is now known as racedo
=== Guest90830 is now known as Cracknel
=== Claudinux__ is now known as Claudinux
=== mmrazik is now known as mmrazik|lunch
=== mmrazik|lunch is now known as mmrazik
=== dpb__ is now known as dpb_
=== mhall119 is now known as mhall119|lunch
=== rsalveti_ is now known as rsalveti
=== Ursinha_ is now known as Ursinha
jdstrandhi !18:02
meetingologyMeeting started Mon Mar 18 18:03:27 2013 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.18:03
meetingologyAvailable commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired18:03
jdstrandThe meeting agenda can be found at:18:03
jdstrand[LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting18:03
jdstrand[TOPIC] Announcements18:04
=== meetingology changed the topic of #ubuntu-meeting to: Announcements
jdstrandChrisCoulson moved over to the security team as our browser security engineer. Chris has been a long-time friend to the security team as the Mozilla maintainer on the desktop team. Welcome Chris! :)18:04
sbeattieWoot! Welcome, chrisccoulson!18:05
sarnoldhunh, I never noticed that extra 'c' :)18:05
chrisccoulsonhah, that confuses people ;)18:05
sarnoldtab-complete for the brain missed it entirely :) welcome :)18:05
jdstrandme either-- that will make my irssi commands interesting :)18:05
chrisccoulsonall of my names begin with C. I'll let you try to guess what my other name is ;)18:05
jdstrandmaybe in another channel :P18:06
jdstrandThanks to Christian Kuersteiner (ckuerste) who provided a debdiff for precise for tinyproxy (LP: #1154502) and a debdiff for oneiric for tomcat7 (LP: #1115053). Your work is very much appreciated and will keep Ubuntu users secure. Great job!18:06
ubottuLaunchpad bug 1154502 in tinyproxy (Ubuntu Precise) "Multiple open vulnerabilities in tinyproxy" [High,Fix released] https://launchpad.net/bugs/115450218:07
ubottuLaunchpad bug 1115053 in tomcat7 (Ubuntu Precise) "Multiple open vulnerabilities in tomcat7 in 12.04 and 11.10" [Undecided,Triaged] https://launchpad.net/bugs/111505318:07
jdstrand[TOPIC] Review of any previous action items18:07
=== meetingology changed the topic of #ubuntu-meeting to: Review of any previous action items
jdstrand[TOPIC] Weekly stand-up report18:07
=== meetingology changed the topic of #ubuntu-meeting to: Weekly stand-up report
jdstrandI'll go first18:07
jdstrandI'm on triage this week18:08
jdstrandI'm working on a nova update18:08
jdstrandI've also got another embargoed update18:08
jdstrandthe CVE list is pretty high atm. I hope to work on something else there18:08
=== mhall119|lunch is now known as mhall119
jdstrandI've also got a work item for apparmor dbus policy I need to do before next week18:09
jdstrandI may pick up an audit as well18:09
jdstrandmdeslaur: you're up18:09
mdeslaurI just published a couple of USNs18:09
mdeslaurand I'm on community this week18:09
mdeslaurI'm currently working on perl updates18:10
mdeslaurand will continue going down the list, as usual18:10
mdeslaurjdstrand: we need to send out the EoL notices18:10
mdeslaura bunch of stuff in dying in a month18:10
mdeslaurand that's it from me18:10
chrisccoulsonooh, i like EoL notices ;)18:10
mdeslaursbeattie: you're up18:10
jdstrandmdeslaur: ack18:11
sbeattieI'm on apparmor again this week, working on the display manager blueprint workitems18:11
sbeattieI'm still working on the apparmor dm prototype, still tracking down some memory allocation errors on my part18:11
sbeattieand digging into the mir codebase18:12
sbeattiethat's pretty much it for me. tyhicks: tag18:12
jdstrandtyhicks: is out today18:13
jdstrandjjohansen: you're up18:13
jjohansenI need to finish up with a regression bug 1145234, and then fixing the loading profiles from cache issue.18:13
ubottubug 1145234 in QA Regression Testing "FAIL: parent ptrace(PTRACE_SINGLESTEP) failed - : No such process" [Undecided,Confirmed] https://launchpad.net/bugs/114523418:13
jjohansenAnd then it will be back to the apparmor labeling wi18:13
jdstrandjjohansen: can you elaborate on 1145234?18:13
jdstrandjjohansen: did this come about because of a security update?18:14
jjohansenjdstrand: yes our ptrace backport causes failures on lucid18:14
jdstrandjjohansen: ok, and only lucid? is it just with the backport kernels on lucid?18:15
jjohansenyes only on lucid18:15
jdstrandor even those kernels at all18:15
jjohansenjdstrand: only the lucid kernel with the ptrace backport18:15
jjohansenjdstrand: I know which patch even, however its not that simple as the patch is correct18:16
jjohansenits the logic inbetween the backported patch that is missing that is causing problems18:16
jdstrandso it needs either some more commits or some glue18:17
jjohansenin other words we need to backport more than the 4 patches we are already doing for the bug18:17
* jdstrand nods18:17
* mdeslaur gets out the Elmer's18:17
sarnolddid you guys ever get the exploit to work on lucid?18:17
jjohansensarnold: yes, it was hardy we failed on18:18
sarnoldah :/18:18
jjohansenbut hardy should theoretically be vulnerable as well18:18
jjohansensarnold: your up18:19
sarnoldI'm finishing up the systemd-related MIR audits this week; I've also got the lxc MIR audit outstanding that I'll work on unless jjohansen hands me a new patch set first :)18:20
sarnoldI also upgraded my laptop to raring over the weekend, initial impressions are quite good :) a handful of small bugs to file, but ... yay :)18:20
sarnoldI think that's it for me, chrisccoulson's turn18:21
chrisccoulsonso, for anyone who's not aware, one of the things i've been working on recently is improving our browser automated tests. i've done quite a lot of work for firefox already, but this week i plan to start improving the situation for chromium too18:23
chrisccoulsonstarting with hooking the upstream tests in to jenkins, like we have already for firefox18:23
chrisccoulsonand then replacing our existing manual tests with more automated ones :)18:23
chrisccoulsonand i've got some wiki stuff to read ;)18:23
jdstrandchrisccoulson: how would you characterize the status of the firefox tests?18:24
chrisccoulsonjdstrand, in mostly good shape. there's some failures i don't yet understand, and some random failures too (eg, https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/ARCH=i386,label=adt/lastCompletedBuild/testReport/dom.media.tests/mochitest/test_peerConnection_bug840344_html/ - although we've just established this one is an OOM)18:25
chrisccoulsonbut otherwise, the failure rate is very low. it would be nice to get it to zero though :)18:25
jdstrandchrisccoulson: not saying you should do this for this case, but is it possible to disable individual problematic tests?18:25
=== blitzkrieg3 is now known as jmleddy
jdstrandwe've been looking at doing that with openjdk for example, where some tests are non-deterministic18:26
chrisccoulsonjdstrand, yeah, there's the ability to skip problematic tests. and for some of the testsuites, you can also mark them as failing or random so that they still run (and an expected-fail test that passes will cause a test failure)18:26
jdstrandheh, 'random'18:27
jdstrandchrisccoulson: cool :)18:27
jdstrandchrisccoulson: what releases are currently tested?18:27
chrisccoulsonjdstrand, only raring for now. i'd like to get them running on all releases really though18:27
chrisccoulsoni need to ask jibel about that though :)18:28
jdstrandchrisccoulson: well, since desktop lucid and oneiric are almost EOL, just precise and later would be enough18:28
chrisccoulsonyeah, that makes sense18:28
jdstrandchrisccoulson: you mentioned to me that these are run within an Ubuntu environment, is that right?18:29
chrisccoulsonmozilla are transitioning their test machines to ubuntu, so the upstream tests will be run on ubuntu 12.04 by mozilla as well18:29
chrisccoulsonwhich helps us a bit18:29
jdstrandchrisccoulson: what I am eventually leading to asking is how much we'll be able to trust that these tests are valid for our security builds (it looks like this is against daily too)18:30
jdstrandchrisccoulson: re upstream> that is nice that they are aligned with our (soon to be) oldest supported LTS18:30
chrisccoulsonjdstrand, i suspect there will still be additional high-level testing (eg, making sure flash works). but i hope i can automate that too18:30
jdstrandchrisccoulson: cool-- thanks for the deeper update. we can talk more about this another time. these automated tests will fill an important void for our team18:31
jdstrandchrisccoulson: I may have cut you off. do you have anything else to report?18:32
chrisccoulsonjdstrand, no, i think i'm done now18:32
jdstrand[TOPIC] Highlighted packages18:32
=== meetingology changed the topic of #ubuntu-meeting to: Highlighted packages
jdstrandThe above are some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so. See SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security on Freenode.18:33
jdstrand[TOPIC] Miscellaneous and Questions18:33
=== meetingology changed the topic of #ubuntu-meeting to: Miscellaneous and Questions
jdstrandI think we may want to consider moving our team meeting. I'll take an action to explore that and discuss next week18:34
jdstrand[ACTION] jdstrand to follow-up on potentially changing time of team meeting18:35
meetingologyACTION: jdstrand to follow-up on potentially changing time of team meeting18:35
jdstrandDoes anyone have any other questions or items to discuss?18:35
jdstrandmdeslaur, sbeattie, jjohansen, sarnold, chrisccoulson: thanks!18:38
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology
meetingologyMeeting ended Mon Mar 18 18:38:16 2013 UTC.18:38
meetingologyMinutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-03-18-18.03.moin.txt18:38
meetingologyMinutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-03-18-18.03.html18:38
jjohansenthanks jdstrand18:38
sarnoldthanks jdstrand18:38
sbeattiejdstrand: thanks!18:38
jdstrandsure thing :)18:38
mdeslaurthanks jdstrand!18:39
=== itnet7_ is now known as itnet7
=== Cracknel_ is now known as Cracknel
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
* stgraber waves21:00
* ScottK looks up.21:00
meetingologyMeeting started Mon Mar 18 21:01:26 2013 UTC.  The chair is mdz. Information about MeetBot at http://wiki.ubuntu.com/meetingology.21:01
meetingologyAvailable commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired21:01
mdzkees, ayt?21:02
mdzI don't seem to have a list of actions from the previous meeting21:02
mdzI'll have to dig it out of IRC logs unless someone has it handy21:02
stgrabermdz: only action was for me to setup the two new flavours21:02
stgrabermdz: which is 90% done, I think we're just missing Ubuntu GNOME on the iso tracker21:02
mdz#topic action review21:02
=== meetingology changed the topic of #ubuntu-meeting to: action review
mdzstgraber to create packagesets + upload teams for Kylin and UbuntuGnome21:02
mdz#topic Agenda21:03
=== meetingology changed the topic of #ubuntu-meeting to: Agenda
mdzhttps://wiki.ubuntu.com/TechnicalBoardAgenda has:21:03
mdzi.e. "Examine sabdfl's updated release management straw man"21:04
mdzand that's it21:04
mdzanything else for the agenda?21:04
mdzthere's this leadership meeting that Jono asked about: https://lists.ubuntu.com/archives/technical-board/2013-March/001536.html21:04
cjwatsonI suspect the release thing will keep us busy21:04
mdz#topic Proposed changes to release management21:05
=== meetingology changed the topic of #ubuntu-meeting to: Proposed changes to release management
mdz#link https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html21:05
mdzso the core of this seems to be phasing out the non-LTS releases21:06
stgraberok, so who do we have here for this discussion?21:06
infinityOr, rather, reducing their support cycle.21:06
stgraberrickspencer3: around?21:07
rickspencer3I'm hear, fwiw21:07
rickspencer3so, what infinity said21:07
* xnox is just lurking.21:07
mdzah yes, this is newer than what I'd read21:08
cjwatsonNewer and quite different, I suspect - you'll want to catch up21:08
* lool is watching too21:08
mdzyes, sorry I'm a bit behind on this, it's been a busy week21:08
* ogra_ waves from the balcony21:09
mdzso what questions or concerns do folks have?21:09
stgraberso from what I remember we appear to have some kind of consensus around shortening the support length of regular releases to 7 or 8 months21:09
infinityI'm with the majority on the supporting the reduced lifecycle, but thinking 8 is more appropriate than 7, while we're bikeshedding.21:10
stgrabertherefore making reducing the number of releases we need to SRU fixes to and reducing the amount of work the security and kernel team have to do21:10
cjwatsonThat seems to have been fairly broadly supported by mail; the exact details are bikeshed, but most people seem to prefer 821:10
mdzthe previous proposal sounded more like debian testing + long term releases, this one sounds more like RHEL+Fedora21:10
cjwatson(In my biased assessment)21:10
brycemdz, one other item if there's room in the agenda - MRE for xserver.  Proposal is in the techboard  list's moderation queue.21:10
mdzbryce, ok, please add to the wiki as a reminder21:10
* cjwatson processes the mod queue21:10
mdzI'm not sure if we will get to it given we have a meaty topic21:11
brycemdz, will do21:11
cjwatsonI think there probably isn't enough time for the board to process something received just now21:11
stgraberbryce: we're usually happy to process those by e-mail so we can do that if as we suspect the release discussion ends up taking the rest of the meeting21:11
cjwatsonIt's out of the mod queue though21:11
micahgfrom a quality perspective, 9 would seemingly be the sweet spot at the moment in that it mirrors the LTS cycle (.1 is usually 3 months after release), meaning that most bugs that will be fixed are probably fixed by then21:11
mdzit seems like the release proposal includes several parts which could potentially be considered separately21:12
cjwatsonHave we seen the indicated strawman from the kernel team on LTS kernel maintenance yet?21:12
ScottKFWIW, Kubuntu would like 9.21:12
mdze.g. reducing the support duration for interim releases seems fairly uncontroversial21:12
cjwatsonmonths> TBH I'm easy as long as we reduce the overlap count21:12
ogasawaracjwatson: it's essentially what we have written up at https://wiki.ubuntu.com/Kernel/LTSEnablementStack21:12
mdzare folks open to breaking it up a little so we can close out some of the items?21:12
loolyes, there are proposed changes to LTS point releases too21:12
cjwatsonmdz: definitely21:12
infinitymdz: That seems reasonable.21:12
brycestgraber, that would be fine (and probably sufficient for this).  Thanks.21:12
ScottKFor those catching up, Kubuntu, as a project, did a comprehensive review of the proposal.  https://lists.ubuntu.com/archives/technical-board/2013-March/001553.html21:12
stgrabermdz: I think it's the only way to get anything done in this meeting, so +1 :)21:13
cjwatsonogasawara: So my reading is that that indicates rolling Q-kernel-on-12.04 users forward, rather than continuing to support the Q kernel?21:13
cjwatsonWait, bad example21:13
mdz#subtopic Support duration for interim releases21:14
ogasawaracjwatson: no, we agreed to support them to the LTS, not roll forward21:14
cjwatsonR-kernel-on-12.04 would be rolled forward in, er, 13.04 + 8/9 months21:14
cjwatsonIf we stop 13.04 support then21:14
micahgmdz: can we call them regular releases as kees suggested?21:14
micahginterim implies not important (to paraphrase)21:14
mdzI didn't see that. I'm not fussed about the name personally21:14
ogra_yeah, that "interim" thing is an awful term21:14
mdz"standard" is what we called them once upon a time21:15
cjwatsonogasawara: Mark's proposal calls for 13.04 support to cease before 14.04 LTS; I'm not clear whether https://wiki.ubuntu.com/Kernel/LTSEnablementStack takes that into account21:15
micahgthat works fine too21:15
cjwatsonI guess this is more on the LTS-support topic, though21:15
ogasawaracjwatson: we initially agreed that we would support each enablement stack for 18mo, ie naturally support duration, but with the proposal to the TB, I think we should support each until the 14.04.1 release21:15
ogasawaracjwatson: so that would be the only deviation from what we have today21:16
mdzwhat's the specific issue for the TB to arbitrate here, on the topic of maintenance for regular releases?21:16
cjwatsonogasawara: I have some questions/concerns there, but should probably hold them off until we reach the relevant subtopic21:16
=== Ursinha_ is now known as Ursinha
infinitymdz: I think it just boils down to "do we cut the support cycle shorter" and "how long".21:16
=== rsalveti_ is now known as rsalveti
infinitymdz: The former seems to have broad agreement already, the latter needs a short bikeshed and vote, I imagine.21:17
rickspencer3I might add "and starting with which standard release"21:17
infinityOh, and that.21:17
infinityI'd prefer to start with R.21:17
mdzdo we have representation from the security team here today?21:17
rickspencer3me too21:17
infinityjdstrand: You paying attention?21:17
* jdstrand reads backscroll21:18
ogasawaracjwatson: I'm happy to follow up via email if needed (might be easier)21:18
cjwatsonIf we had a way to poll our users in any kind of effective way, I'd like to explore retroactively starting with 12.10; but as it stands, I think that would be as likely as not to send a bad message and act as a distraction21:18
mdzjdstrand, just looking for input on the question of maintenance duration for regular releases21:18
cjwatson(aka, commitments are hard to unwind once you've made them)21:19
infinitycjwatson: Comm... What you said.21:19
jdstrandWe are prepared to do 18 months if needed. I think 8 months seems reasonable for people to migrate, but we'll support 7+21:19
infinitycjwatson: We can revisit SRU policy to keep 12.10 maintenance as lightweight as possible, but I think dropping support entirely would be in very poor form.21:19
jdstrandie, we're flexible :)21:20
cjwatsoninfinity: Yeah21:20
cjwatsonI would definitely like to pare back the extent to which developers feel they have to do dual uploads to precise/quantal, because I do think that's a bottleneck21:20
ScottKI think we can solve that within the SRU team.21:21
infinityAbsolutely.  But we're on a tangent again. ;)21:21
cjwatsonBut I'm not going to press for dropping support entirely21:21
rickspencer3cjwatson, could we take that as a future TB discussion point?21:21
infinityAnd yes, we can solve that without TB intervention.  We're good at rejecting uploads.21:21
infinityReally good.21:21
mdzdoes anyone have a serious objection to reducing the maintenance lifetime by at least 9 months?21:21
* ScottK likes precisely 9 months ....21:22
stgraberright, SRU policies can be discussed on ubuntu-release@l.u.c and be brought to the TB if the SRU team feels they need extra power or want to run something by us (though we have a reasonable overlap between the two teams ;))21:22
infinitymdz: From reviewing the thread, I think 9 would make most everyone happy.  8 would make almost everyone happy.  7 would make Mark happy, and the rest of us nervous.21:22
mdzright, to rephrase: does anyone feel strongly that maintenance ought to be *longer* than 9 months?21:22
cjwatsonSo, on 9 months, the arguments that (a) this brings us up to the LTS.1 sweet spot and (b) this lines up with upstream point release cadence (at minimum in KDE) are ones I find compelling21:22
mdztrying to bisect the problem ;-)21:22
jdstrandI think it was implied in my last comment, but 9 is fine by the security team21:23
stgraberI'm perfectly happy with 9 months. I'd only be nervous with < 8 months.21:23
mdzsounds like no objections21:23
mdzwould anyone be negatively impacted by making it 9 months exactly?21:24
mdzi.e. could anyone not live with that?21:24
infinityI think cutting our support cycle in half is already such a huge win that quibbling over another month or two isn't worth it.  If there are compelling reasons for 9 (and there seem to be), I'm all for it.21:25
mdzinfinity, is it implied by your comment that Mark would be dissatisfied with that?21:25
mdza bit odd that he doesn't seem to be here21:25
infinitymdz: Oh, he hasn't expressed concern about people wanting 8/9, just that he initially wanted 7.21:25
cjwatsonrickspencer3: Do you know if Mark has expressed a strong opinion on this particular bikeshed?21:25
rickspencer3cjwatson, I do not know21:26
cjwatsonOK.  It sounds like 9 is a good common position, then21:26
* xnox o/21:26
* micahg apologizes, but has to go21:26
cjwatsonxnox: ?21:27
infinityI'm pretty comfy with the 3 month overlap, personally.  While people upgrading Ubuntu->Ubuntu (or any in-archive flavour) can do their testing and upgrading fairly rapidly, 3 months gives derivatives a bit of breathing room to rebase.21:27
xnoxif we decide that raring gets 9 month support there will be no overlap between quantal EOL and raring EOL, unless quantal support is extended.21:27
ScottKBut "S" will be out before then.21:27
infinityxnox: That's... What Scott said.21:27
ogra_xnox, people are forced to upgrade21:28
mdzok, seems like we can put 9 months to a vote21:28
stgraberxnox: we're also discussing allowing upgrading by more than a single release21:28
cjwatsonquantal support is probably a separate topic for at least two reasons, but ... what stgraber said21:28
infinity(And leads to another discussion topic, where I think we need to support better upgrade paths)21:28
xnoxstgraber: ok.21:28
stgrabermdz: do we want to also bundle what release to start the 9 months support with as part of the vote, or do you want to split?21:29
mdz#vote Reduce maintenance period for regular (non-LTS) Ubuntu releases from 18 months to 9 months (starting with release TBD)21:29
meetingologyPlease vote on: Reduce maintenance period for regular (non-LTS) Ubuntu releases from 18 months to 9 months (starting with release TBD)21:29
meetingologyPublic votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)21:29
mdzstgraber, ;-)21:29
stgrabermdz: that answers it ;)21:29
meetingology+1 received from stgraber21:29
meetingology+1 received from mdz21:29
meetingology+1 received from cjwatson21:29
mdzwe're missing kees, pitti and soren, yes?21:30
mdzso that's all TB members present?21:30
cjwatsonUnfortunately narrow quorum for such an important topic21:30
mdzwe can ask for comments/votes by email as well21:31
mdzif you want21:31
infinityI can pretend to be kees.21:31
ogra_xchat agrees, you are equally red colored ...21:31
mdza discussion about quorum should ideally have preceded the start of a vote21:31
meetingologyVoting ended on: Reduce maintenance period for regular (non-LTS) Ubuntu releases from 18 months to 9 months (starting with release TBD)21:32
meetingologyVotes for:3 Votes against:0 Abstentions:021:32
meetingologyMotion carried21:32
cjwatsonSorry, didn't mean to derail21:32
* cjwatson looks at the mails from the relevant people21:32
mdzI'm comfortable with meeting quorum on this particular subtopic21:32
cjwatsonkees expressed support for truncating the support cycle21:32
cjwatsonSo did soren and pitti21:32
mdzthe next topic should probably be when to make the change effective21:33
mdz#subtopic effective date for new maintenance period for regular releases21:33
mdzwhat are the main options?21:33
infinitys/effective date/effective release/21:33
mdzfair enough21:34
infinityThe former being somewhat ambiguous as to what it will apply to.21:34
cjwatsonI guess the main options are 12.10, 13.04, later21:34
cjwatsonI thought we'd essentially disposed of that part of the discussion above, but as you like :)21:35
infinity13.04 being, I think, the "obvious" middle ground between "we want this done ASAP" and "we don't want to shaft previously-assumed commitments".21:35
mdz12.10 doesn't seem workable for reasons discussed above, i.e. breaking promises to users retroactively21:35
cjwatsonIt phases in effort savings over time rather than cutting things off immediately, but that's life, I think21:35
mdz"Maintenance updates will be provided for Ubuntu 12.10 for 18 months, through April 2014."21:35
cjwatsonWell, "immediately" would in fact be at minimum four months from now in any event21:36
cjwatson(That being 12.10 + 9 months)21:36
mdzI haven't heard a compelling reason why we should go back on that promise21:36
mdzhow about 13.04? any concerns to discuss there?21:36
cjwatsonNo, I agree.  It's an option, and we are right to consider it, but I think we're also right to reject it21:36
ScottKIdeally this would kick in at the start of an LTS cycle, but that's a long time from now.21:36
stgraberright, I don't think we should change anything we already released. Now the question is 13.04 vs 13.10.21:37
infinityScottK: What we were discussing in #-release should likely cover the scariness of this happening between LTSen.21:37
mdzyes, that seems a lot to ask, especially if the goal is to help focus limited attention and resources sooner is much better than later21:37
ScottKinfinity: Agreed.21:37
* ScottK isn't arguing for this starting for 14.10, but putting out there as a natural spot in the meta-cycle. As infinity said, it's manageable for 13.04/10.21:38
mdzso there's some preference for 13.04 as it's sooner, so we can start implementing this sooner and get the benefits of less maintenance load sooner21:39
cjwatsonI don't think shortening 13.04 to 9 months is going to be a surprise to all that many people at this point.21:39
mdzunless there's a specific reason to prefer 13.10, that seems like enough of a tiebreaker to me21:39
stgraberright, so based on the above, the options really are 13.04, 13.10 or 14.10 (14.04 being special as it's an LTS)21:39
cjwatsonFrom the discussion I think we can just have an up/down vote on 13.40.21:40
mdzI think 14.10 is right out; if that's the fastest we can move as a project then we are doomed :-)21:40
mdzcjwatson, agreed21:40
stgrabernow with the upgrade changes being discussed, I'm happy to do that with 13.0421:40
mdz#vote Implement the above change to the maintenance schedule effective in 13.04 and later21:40
meetingologyPlease vote on: Implement the above change to the maintenance schedule effective in 13.04 and later21:41
meetingologyPublic votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)21:41
meetingology+1 received from mdz21:41
meetingology+1 received from stgraber21:41
meetingology+1 received from cjwatson21:41
meetingologyVoting ended on: Implement the above change to the maintenance schedule effective in 13.04 and later21:42
meetingologyVotes for:3 Votes against:0 Abstentions:021:42
meetingologyMotion carried21:42
mdzI'm looking at #3 on https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html21:42
mdzit doesn't seem like there's much substance to it21:42
mdzjust a "designation"21:42
mdzis there any practical impact to this part of the proposal?21:42
cjwatsonAs stated it implies having an unstable series, which is quite a big deal operationally :)21:43
infinityThe second half of it is actually a fairly large technical snafu hidden in a quick aside.21:43
cjwatsonSorry, not unstable, I mean a perpetual testing21:43
infinityAnd given how quickly we freeze/release, I'm not sure it's worth it.21:43
mdzcjwatson, oh?21:43
cjwatsonWe could perhaps meet the request by having an alias21:44
infinityWe've already been working to compress the FF->release window, etc.21:44
cjwatsonI actually always wondered why we never did suite aliasing, and I think the answer is "inertia"21:44
infinitycjwatson: Oh, sure, we could absolutely do Debian-style symlink aliases.21:44
cjwatsonBut having a dists/development -> raring (at the current time) symlink wouldn't be that big a deal21:44
mdzwe didn't do it because we didn't want the inter-release upgrade behavior that Debian had21:44
infinitycjwatson: That's much more lightweight than what I assumed was meant here.21:44
mdzcjwatson, yeah, that's what I assumed this would entail - a symlink which always pointed to the "rolling release"21:45
infinitymdz: You'd agree that if we only alias "development", but not "stable", etc, then we don't have the Debian problem?21:45
mdzwhether that's an eternal suite or one which changes sometimes21:45
cjwatsoninfinity: I may be being presumptuous, but I had the impression Mark's proposal was fungible in terms of exact implementation21:45
mdzinfinity, yes21:45
infinityI'd be all for that.21:45
cjwatsonThen it's a bikeshed about the name which we don't need to have here21:45
infinityI read it as a heavyweight "do development in something sid-like, fork for release, repeat".21:45
mdzthe proposal asks the TB to evaluate whether that's a good idea21:46
cjwatsonThat said, that doesn't answer the question of PPAs easily building for just the "edge" release21:46
mdzI'd be comfortable delegating that to the people running the archive21:46
stgrabercjwatson: how much pain would you expect to result from opening the next dev cycle at the same time we hit final freeze (or even FF)? (and changing the "development" symlink to point to it at that point)21:46
mdz(the implementation)21:46
cjwatsonstgraber: As it stands it's not possible - it causes madness in the implementation21:46
mdzwith a goal of making it possible to stay on the rolling release without explicit intervention from the user21:46
infinitystgraber: Soyuz can't deal with two active releases.21:47
ogra_and madness for doko perhaps :)21:47
infinitystgraber: That's likely a solvable problem, but not a solved one currently.21:47
cjwatsonThe problem I have with it is actually more fundamental than the implementation21:47
mdzcjwatson, do tell21:47
cjwatsonI think that doing that distracts developer attention into ooh-new-shiny at exactly the point we want them to be doing final polish on the release21:47
infinityIt also, of course, sucks resources from the freeze and release.21:47
infinitycjwatson: Jinx.21:47
ScottKWe've got permission to open backports pre-release for stuff people HAVE to have.21:48
cjwatsonWhich is why I've never put much energy into unhardcoding things like the one-development-series assumption in Soyuz, and sorting out the ancestry madness that I believe to exist21:48
cjwatson(Er, don't ask me to expand too much on the latter - I think it's based on a comment from Celso from about five years back)21:48
stgraberyeah, that's a fair point. We need developers to move from the "implement new cool stuff" to "fixing bugs" mode for at least a few weeks in the cycle.21:48
cjwatsonAnyway, I don't think this stops us having a dev -> whatever symlink21:49
mdzcjwatson, hmm, maybe I'm misreading this21:49
infinitySo.  Back to the symlink topic.  That doesn't solve Mark's magical PPA that always targets devel strawman.21:49
mdzbut it wasn't implicit to me that this proposal meant changing anything in terms of the freeze21:49
cjwatsonI hear we have a release sprint at some point with the LP guys; perhaps we should put this on the table for that21:49
infinitymdz: That was Colin and I responding to Stephane.21:49
cjwatsonmdz: It didn't.  I was responding specifically to stgraber's comment.21:49
cjwatson21:46 <stgraber> cjwatson: how much pain would you expect to result from opening the next dev cycle at the same time we hit final freeze (or even FF)? (and changing the "development" symlink to point to it at that point)21:49
mdzjust making it possible to stay on the newest/development release continuously21:49
cjwatsoninfinity: How about we get together at a convenient point this week and see if we can work out something that would work, and take it to the Australian cabal for sanity-checking?21:50
mdzso would the TB be comfortable taking a vote on declaring the project's intent that we should make it possible for users to track the development focus continuously and easily, while leaving the exact implementation open?21:51
cjwatsonI don't think we're going to invent something in ten minutes21:51
infinitycjwatson: So, the PPA thing could be "solved" by doing a mass source+bin copy from rel-1 to rel when we open a new release.  Would grind ppa.lp.net to a halt for a ridiculous amount of time while it republished the world, though.21:51
infinitycjwatson: But yes, we can discuss that out of band.21:51
cjwatsonmdz: yes21:51
xnoxi have been running raring from week1 and for about 2 months, I had quantal-updates & quantal-security enabled. I was still receiving packages from quantal pockets now and then. If opening a new dev-series will solve the problem of fixing next release first, I'm up for it.21:52
stgraberI think at least the general idea of symlinking "development" (or similar) to the current dev release makes sense and doesn't hurt.21:52
* infinity nods.21:52
xnoximho that would mean freasing release pocket at feature-freeze.21:52
infinityxnox: That's a process failure that's beyond the TB to fix.  Bring it up with -release later, though.21:52
stgraberassuming people have to change their apt config manually to that and we don't do weird things like using this by default in our pre-release images21:52
dokocjwatson, it probably could help preparing the opening of the new release. however this currently can be done too by using non-virtualized PPA's, only that using the new release would be more visible21:52
mdz#vote Enable users to continuously track the development focus of Ubuntu as a "rolling release" rather than having to explicitly upgrade21:53
meetingologyPlease vote on: Enable users to continuously track the development focus of Ubuntu as a "rolling release" rather than having to explicitly upgrade21:53
meetingologyPublic votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)21:53
meetingology+1 received from cjwatson21:53
mdzwording ok?21:53
meetingology+1 received from mdz21:53
meetingology+1 received from stgraber21:54
cjwatson"rolling release" has a ton of baggage21:54
mdzsuggested alternative wording?21:54
stgraberI don't like the rolling release wording either (because it's not)21:54
ogra_rolling development release ?21:54
infinityDevelopment release.  Or Development series.21:54
cjwatsondrop 'as a "rolling release"'?21:54
cjwatsonThe sentence is fine without that21:54
stgrabercjwatson: +121:54
mdz#vote Enable users to continuously track the development focus of Ubuntu without having to explicitly upgrade21:54
meetingologyVoting still open on: Enable users to continuously track the development focus of Ubuntu as a "rolling release" rather than having to explicitly upgrade21:54
infinityIt's not a release.  And rolling itself has other baggage.21:54
meetingology-1 received from mdz21:54
meetingology+1 received from cjwatson21:54
cjwatsonmdz: oh?21:55
mdztrying to find a way to cancel the vote I alread ystarted21:55
AlanBellyou have to endvote21:55
mdzthat will say that we confirmed that thing that we just agreed to change the wording of21:55
meetingology-1 received from stgraber21:55
cjwatsonhow about we all -1 and then endvote21:55
meetingology-1 received from cjwatson21:55
meetingologyVoting ended on: Enable users to continuously track the development focus of Ubuntu as a "rolling release" rather than having to explicitly upgrade21:55
meetingologyVotes for:0 Votes against:3 Abstentions:021:55
meetingologyMotion denied21:55
AlanBellyeah, do that21:55
mdz#vote Enable users to continuously track the development focus of Ubuntu without having to explicitly upgrade21:56
meetingologyPlease vote on: Enable users to continuously track the development focus of Ubuntu without having to explicitly upgrade21:56
meetingologyPublic votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)21:56
meetingology+1 received from mdz21:56
mdzsorry for all the noise21:56
meetingology+1 received from cjwatson21:56
meetingology+1 received from stgraber21:56
meetingologyVoting ended on: Enable users to continuously track the development focus of Ubuntu without having to explicitly upgrade21:56
meetingologyVotes for:3 Votes against:0 Abstentions:021:56
meetingologyMotion carried21:56
mdzok that leaves the question of doing additional maintenance work on LTS releases21:56
cjwatsonto me, lots of this was stuff we're already doing21:56
cjwatsonbut then there's a handwave about lots more stuff we could do21:56
mdzwhat needs deciding?21:56
ScottK"required upgrades to newer versions of platform components" was the major change.21:57
infinityAnd of the stuff we're already doing, some of it could be done better, but that's implementation, not policy.21:57
stgraberto what extent do we need TB approval for that? It sounded to me like most of it can be done through the regular process by just having the SRU team change its criteria a bit21:57
mdzwhat determines which upgrades are "required"?)21:57
ScottKThat seems to me approximately the last thing we should inflict on users of LTS releases.21:57
cjwatson"required upgrade" I think means "in -updates with the same package name21:57
infinityI think there's a huge can of worms here, where assuming stable API/ABI isn't always true.21:58
mdzcjwatson, that seems tautological21:58
cjwatsonrather than the X-stack approach of "rename a bunch of libraries", or putting things in -backports or PPAs21:58
cjwatson^- why it's not tautological21:58
infinityWe do this already for leaf packages (Firefox), and that's fine, but core system libraries WILL break your system when you didn't think they would.21:58
cjwatsonI think there are lots of things we can/should split out of this, but I'm not sure we're going to get it done here21:58
mdzcjwatson, I'm not sure I follow21:58
cjwatsonthings I can think of include:21:58
mdzso the status quo is that there's a set of stuff that goes into -updates21:59
cjwatson - applying better autotesting to -proposed -> -updates transitions21:59
cjwatson - some kind of blessed-PPA system21:59
mdzwhat is proposed to change about htat?21:59
micahginfinity: firefox has a reason that it's needed for security updates21:59
cjwatson - better -backports infrastructure and advertising it better21:59
cjwatson - explicit SRU policy changes to weaken restrictions on some packages21:59
cjwatson - probably more21:59
mdzthe example given is upgrading Unity21:59
infinitycjwatson: I think those break into two broad categories of "stuff that's just implementation fluff" and "stuff that needs broader discussion, not a TB vote".22:00
cjwatsonmdz: I am trying to clarify Mark's "required upgrades" vs. "optional upgrades" terminology into terms that the rest of us understand22:00
mdzok, we're out of time22:00
stgraberI think I'd ideally like to see backports be replaced by blessed PPAs so we can better cover the case where we backport a whole stack and may want to support multiple version of that stack in parallel. But this would likely be a lengthy discussion that should only reach the TB when we have a concrete proposal.22:00
cjwatson"required upgrades" -> we put it in -updates and you get it automatically22:00
mdzseems like we can pick this up in 2 weeks given it doesn't change anything until next year, right?22:00
mdzor is it proposed to be retroactive?22:00
cjwatson"optional upgrades" -> we put it in something like -updates, but you have to opt in in some way (e.g. selecting a different kernel flavour)22:00
xnoxwebkit is joining firefox support model for LTS releases.22:01
cjwatsonI think we can pick it up in two weeks either way, and/or continue by mail22:01
ScottKRe Unity, look at the number of packages affected by bug 1154229, the new  Unity stack FFe, and ask if that's reasonable to deal with post-release.22:01
ubottubug 1154229 in unity-scope-gdrive (Ubuntu) "[FFE] New Unity Dash" [Undecided,Triaged] https://launchpad.net/bugs/115422922:01
infinitymdz: Some of this already applies to precise, and may be retroactive if we decide to do things differently, but I don't think the LTS stuff is urgent.22:01
micahgxnox: same thing, security reasons22:01
mdzok, we'll pick up the rest at the next meeting22:01
mdzwhich will be chaired by...22:01
mdz#topic chair for next meeting22:01
=== meetingology changed the topic of #ubuntu-meeting to: chair for next meeting
cjwatsonUnity is I think an unfortunate example, as I tried to cover in https://lists.ubuntu.com/archives/technical-board/2013-March/001531.html22:01
mdzI think we're going alpha-by-nick, no?22:02
mdzso it would be pitti?22:02
stgraberdidn't pitti cover for a missing chair lately?22:02
mdzwho is conveniently not present to object. DONE22:02
mdzyes he did22:02
stgraberI think he did 2 meetings ago22:02
mdzI don't recall who it was though22:02
stgraberso it probably should be soren then (or me)22:02
mdzok, soren then22:02
mdzNext chair: soren22:02
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology
meetingologyMeeting ended Mon Mar 18 22:02:59 2013 UTC.22:03
meetingologyMinutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-03-18-21.01.moin.txt22:03
meetingologyMinutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-03-18-21.01.html22:03
mdzthanks all22:03
ogra_thanks !22:03
cjwatsonThat was actually more of that topic than I expected to cover22:03
cjwatsonSo thanks22:03
stgrabermdz: thanks for chairing!22:03
loolgood night22:03
JackYuthank you:)22:03
stgraberScottK: I think I'd like to talk with the current backports team at some point in the near future to figure out whether we can get some kind of proposal which would cover the way we currently do backports and the way some people currently do them (outside of -backports).22:04
=== Alepina is now known as Fuchs
ScottKstgraber: Sure thing.22:50

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