=== 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 [18:02] \o [18:02] hi ! [18:02] o/ [18:02] \o/ [18:03] #startmeeting [18:03] Meeting started Mon Mar 18 18:03:27 2013 UTC. The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [18:03] Available 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 #votesrequired [18:03] The meeting agenda can be found at: [18:03] [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting [18:04] [TOPIC] Announcements === meetingology changed the topic of #ubuntu-meeting to: Announcements [18:04] ChrisCoulson 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] chrisccoulson [18:05] :) [18:05] Woot! Welcome, chrisccoulson! [18:05] welcome! [18:05] hunh, I never noticed that extra 'c' :) [18:05] hah, that confuses people ;) [18:05] tab-complete for the brain missed it entirely :) welcome :) [18:05] me either-- that will make my irssi commands interesting :) [18:05] all of my names begin with C. I'll let you try to guess what my other name is ;) [18:06] Custard? [18:06] lol [18:06] maybe in another channel :P [18:06] Thanks 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:07] Launchpad bug 1154502 in tinyproxy (Ubuntu Precise) "Multiple open vulnerabilities in tinyproxy" [High,Fix released] https://launchpad.net/bugs/1154502 [18:07] Launchpad bug 1115053 in tomcat7 (Ubuntu Precise) "Multiple open vulnerabilities in tomcat7 in 12.04 and 11.10" [Undecided,Triaged] https://launchpad.net/bugs/1115053 [18:07] [TOPIC] Review of any previous action items === meetingology changed the topic of #ubuntu-meeting to: Review of any previous action items [18:07] n/a [18:07] [TOPIC] Weekly stand-up report === meetingology changed the topic of #ubuntu-meeting to: Weekly stand-up report [18:07] I'll go first [18:08] I'm on triage this week [18:08] I'm working on a nova update [18:08] I've also got another embargoed update [18:08] the CVE list is pretty high atm. I hope to work on something else there === mhall119|lunch is now known as mhall119 [18:09] I've also got a work item for apparmor dbus policy I need to do before next week [18:09] I may pick up an audit as well [18:09] mdeslaur: you're up [18:09] I just published a couple of USNs [18:09] and I'm on community this week [18:10] I'm currently working on perl updates [18:10] and will continue going down the list, as usual [18:10] jdstrand: we need to send out the EoL notices [18:10] \o/ [18:10] a bunch of stuff in dying in a month [18:10] and that's it from me [18:10] ooh, i like EoL notices ;) [18:10] sbeattie: you're up [18:11] mdeslaur: ack [18:11] I'm on apparmor again this week, working on the display manager blueprint workitems [18:11] I'm still working on the apparmor dm prototype, still tracking down some memory allocation errors on my part [18:12] and digging into the mir codebase [18:12] that's pretty much it for me. tyhicks: tag [18:13] tyhicks: is out today [18:13] jjohansen: you're up [18:13] I need to finish up with a regression bug 1145234, and then fixing the loading profiles from cache issue. [18:13] bug 1145234 in QA Regression Testing "FAIL: parent ptrace(PTRACE_SINGLESTEP) failed - : No such process" [Undecided,Confirmed] https://launchpad.net/bugs/1145234 [18:13] s/:// [18:13] And then it will be back to the apparmor labeling wi [18:13] jjohansen: can you elaborate on 1145234? [18:14] jjohansen: did this come about because of a security update? [18:14] jdstrand: yes our ptrace backport causes failures on lucid [18:15] jjohansen: ok, and only lucid? is it just with the backport kernels on lucid? [18:15] yes only on lucid [18:15] or even those kernels at all [18:15] jdstrand: only the lucid kernel with the ptrace backport [18:16] jdstrand: I know which patch even, however its not that simple as the patch is correct [18:16] hrm [18:16] ok [18:16] its the logic inbetween the backported patch that is missing that is causing problems [18:17] so it needs either some more commits or some glue [18:17] in other words we need to backport more than the 4 patches we are already doing for the bug [18:17] yeah [18:17] * jdstrand nods [18:17] * mdeslaur gets out the Elmer's [18:17] did you guys ever get the exploit to work on lucid? [18:18] sarnold: yes, it was hardy we failed on [18:18] ah :/ [18:18] but hardy should theoretically be vulnerable as well [18:19] sarnold: your up [18:20] I'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] I also upgraded my laptop to raring over the weekend, initial impressions are quite good :) a handful of small bugs to file, but ... yay :) [18:21] nice [18:21] I think that's it for me, chrisccoulson's turn [18:23] so, 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 too [18:23] starting with hooking the upstream tests in to jenkins, like we have already for firefox [18:23] and then replacing our existing manual tests with more automated ones :) [18:23] and i've got some wiki stuff to read ;) [18:24] chrisccoulson: how would you characterize the status of the firefox tests? [18:25] jdstrand, 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] but otherwise, the failure rate is very low. it would be nice to get it to zero though :) [18:25] chrisccoulson: not saying you should do this for this case, but is it possible to disable individual problematic tests? === blitzkrieg3 is now known as jmleddy [18:26] we've been looking at doing that with openjdk for example, where some tests are non-deterministic [18:26] jdstrand, 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:27] heh, 'random' [18:27] chrisccoulson: cool :) [18:27] chrisccoulson: what releases are currently tested? [18:27] jdstrand, only raring for now. i'd like to get them running on all releases really though [18:28] i need to ask jibel about that though :) [18:28] chrisccoulson: well, since desktop lucid and oneiric are almost EOL, just precise and later would be enough [18:28] yeah, that makes sense [18:29] chrisccoulson: you mentioned to me that these are run within an Ubuntu environment, is that right? [18:29] mozilla are transitioning their test machines to ubuntu, so the upstream tests will be run on ubuntu 12.04 by mozilla as well [18:29] which helps us a bit [18:30] chrisccoulson: 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] chrisccoulson: re upstream> that is nice that they are aligned with our (soon to be) oldest supported LTS [18:30] jdstrand, i suspect there will still be additional high-level testing (eg, making sure flash works). but i hope i can automate that too [18:31] chrisccoulson: cool-- thanks for the deeper update. we can talk more about this another time. these automated tests will fill an important void for our team [18:32] chrisccoulson: I may have cut you off. do you have anything else to report? [18:32] jdstrand, no, i think i'm done now [18:32] [TOPIC] Highlighted packages === meetingology changed the topic of #ubuntu-meeting to: Highlighted packages [18:32] http://people.canonical.com/~ubuntu-security/cve/pkg/extplorer.html [18:33] http://people.canonical.com/~ubuntu-security/cve/pkg/rt-authen-externalauth.html [18:33] http://people.canonical.com/~ubuntu-security/cve/pkg/tinymce.html [18:33] http://people.canonical.com/~ubuntu-security/cve/pkg/msmtp.html [18:33] http://people.canonical.com/~ubuntu-security/cve/pkg/festival.html [18:33] The 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] [TOPIC] Miscellaneous and Questions === meetingology changed the topic of #ubuntu-meeting to: Miscellaneous and Questions [18:34] I think we may want to consider moving our team meeting. I'll take an action to explore that and discuss next week [18:35] [ACTION] jdstrand to follow-up on potentially changing time of team meeting [18:35] ACTION: jdstrand to follow-up on potentially changing time of team meeting [18:35] Does anyone have any other questions or items to discuss? [18:38] mdeslaur, sbeattie, jjohansen, sarnold, chrisccoulson: thanks! [18:38] #endmeeting === 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 [18:38] Meeting ended Mon Mar 18 18:38:16 2013 UTC. [18:38] Minutes (wiki): http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-03-18-18.03.moin.txt [18:38] Minutes (html): http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-03-18-18.03.html [18:38] thanks jdstrand [18:38] thanks jdstrand [18:38] jdstrand: thanks! [18:38] sure thing :) [18:39] thanks jdstrand! === 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 [21:00] * stgraber waves [21:00] * ScottK looks up. [21:00] o/ [21:01] #startmeeting [21:01] Meeting started Mon Mar 18 21:01:26 2013 UTC. The chair is mdz. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [21:01] Available 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 #votesrequired [21:01] Hi [21:02] kees, ayt? [21:02] I don't seem to have a list of actions from the previous meeting [21:02] I'll have to dig it out of IRC logs unless someone has it handy [21:02] mdz: only action was for me to setup the two new flavours [21:02] mdz: which is 90% done, I think we're just missing Ubuntu GNOME on the iso tracker [21:02] #topic action review === meetingology changed the topic of #ubuntu-meeting to: action review [21:02] stgraber to create packagesets + upload teams for Kylin and UbuntuGnome [21:03] done [21:03] ok [21:03] #topic Agenda === meetingology changed the topic of #ubuntu-meeting to: Agenda [21:03] https://wiki.ubuntu.com/TechnicalBoardAgenda has: [21:03] https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html [21:04] i.e. "Examine sabdfl's updated release management straw man" [21:04] and that's it [21:04] anything else for the agenda? [21:04] there's this leadership meeting that Jono asked about: https://lists.ubuntu.com/archives/technical-board/2013-March/001536.html [21:04] I suspect the release thing will keep us busy [21:05] ok [21:05] #topic Proposed changes to release management === meetingology changed the topic of #ubuntu-meeting to: Proposed changes to release management [21:05] #link https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html [21:06] so the core of this seems to be phasing out the non-LTS releases [21:06] ok, so who do we have here for this discussion? [21:06] Or, rather, reducing their support cycle. [21:06] o/ [21:07] rickspencer3: around? [21:07] I'm hear, fwiw [21:07] so, what infinity said [21:07] * xnox is just lurking. [21:08] ah yes, this is newer than what I'd read [21:08] Newer and quite different, I suspect - you'll want to catch up [21:08] * lool is watching too [21:08] yes, sorry I'm a bit behind on this, it's been a busy week [21:09] * ogra_ waves from the balcony [21:09] so what questions or concerns do folks have? [21:09] so from what I remember we appear to have some kind of consensus around shortening the support length of regular releases to 7 or 8 months [21:10] I'm with the majority on the supporting the reduced lifecycle, but thinking 8 is more appropriate than 7, while we're bikeshedding. [21:10] therefore 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 do [21:10] That seems to have been fairly broadly supported by mail; the exact details are bikeshed, but most people seem to prefer 8 [21:10] the previous proposal sounded more like debian testing + long term releases, this one sounds more like RHEL+Fedora [21:10] (In my biased assessment) [21:10] mdz, one other item if there's room in the agenda - MRE for xserver. Proposal is in the techboard list's moderation queue. [21:10] bryce, ok, please add to the wiki as a reminder [21:10] * cjwatson processes the mod queue [21:11] I'm not sure if we will get to it given we have a meaty topic [21:11] mdz, will do [21:11] I think there probably isn't enough time for the board to process something received just now [21:11] bryce: 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 meeting [21:11] It's out of the mod queue though [21:11] from 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 then [21:12] it seems like the release proposal includes several parts which could potentially be considered separately [21:12] Have we seen the indicated strawman from the kernel team on LTS kernel maintenance yet? [21:12] FWIW, Kubuntu would like 9. [21:12] e.g. reducing the support duration for interim releases seems fairly uncontroversial [21:12] months> TBH I'm easy as long as we reduce the overlap count [21:12] cjwatson: it's essentially what we have written up at https://wiki.ubuntu.com/Kernel/LTSEnablementStack [21:12] are folks open to breaking it up a little so we can close out some of the items? [21:12] yes, there are proposed changes to LTS point releases too [21:12] mdz: definitely [21:12] mdz: That seems reasonable. [21:12] stgraber, that would be fine (and probably sufficient for this). Thanks. [21:12] For those catching up, Kubuntu, as a project, did a comprehensive review of the proposal. https://lists.ubuntu.com/archives/technical-board/2013-March/001553.html [21:13] mdz: I think it's the only way to get anything done in this meeting, so +1 :) [21:13] ogasawara: 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] Wait, bad example [21:14] #subtopic Support duration for interim releases [21:14] cjwatson: no, we agreed to support them to the LTS, not roll forward [21:14] R-kernel-on-12.04 would be rolled forward in, er, 13.04 + 8/9 months [21:14] ? [21:14] If we stop 13.04 support then [21:14] mdz: can we call them regular releases as kees suggested? [21:14] interim implies not important (to paraphrase) [21:14] I didn't see that. I'm not fussed about the name personally [21:14] yeah, that "interim" thing is an awful term [21:15] "standard" is what we called them once upon a time [21:15] yeah [21:15] ogasawara: 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 account [21:15] that works fine too [21:15] I guess this is more on the LTS-support topic, though [21:15] cjwatson: 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 release [21:16] cjwatson: so that would be the only deviation from what we have today [21:16] what's the specific issue for the TB to arbitrate here, on the topic of maintenance for regular releases? [21:16] ogasawara: I have some questions/concerns there, but should probably hold them off until we reach the relevant subtopic === Ursinha_ is now known as Ursinha [21:16] mdz: I think it just boils down to "do we cut the support cycle shorter" and "how long". === rsalveti_ is now known as rsalveti [21:17] mdz: The former seems to have broad agreement already, the latter needs a short bikeshed and vote, I imagine. [21:17] agreed [21:17] I might add "and starting with which standard release" [21:17] Oh, and that. [21:17] I'd prefer to start with R. [21:17] do we have representation from the security team here today? [21:17] me too [21:17] jdstrand: You paying attention? [21:18] * jdstrand reads backscroll [21:18] cjwatson: I'm happy to follow up via email if needed (might be easier) [21:18] If 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 distraction [21:18] jdstrand, just looking for input on the question of maintenance duration for regular releases [21:19] (aka, commitments are hard to unwind once you've made them) [21:19] cjwatson: Comm... What you said. [21:19] We 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] cjwatson: 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:20] ie, we're flexible :) [21:20] infinity: Yeah [21:20] I 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 bottleneck [21:21] I think we can solve that within the SRU team. [21:21] Absolutely. But we're on a tangent again. ;) [21:21] But I'm not going to press for dropping support entirely [21:21] cjwatson, could we take that as a future TB discussion point? [21:21] Sure [21:21] And yes, we can solve that without TB intervention. We're good at rejecting uploads. [21:21] Really good. [21:21] does anyone have a serious objection to reducing the maintenance lifetime by at least 9 months? [21:22] * ScottK likes precisely 9 months .... [21:22] right, 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] mdz: 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] right, to rephrase: does anyone feel strongly that maintenance ought to be *longer* than 9 months? [21:22] So, 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 compelling [21:22] trying to bisect the problem ;-) [21:23] I think it was implied in my last comment, but 9 is fine by the security team [21:23] I'm perfectly happy with 9 months. I'd only be nervous with < 8 months. [21:23] sounds like no objections [21:24] would anyone be negatively impacted by making it 9 months exactly? [21:24] i.e. could anyone not live with that? [21:25] I 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] infinity, is it implied by your comment that Mark would be dissatisfied with that? [21:25] a bit odd that he doesn't seem to be here [21:25] mdz: Oh, he hasn't expressed concern about people wanting 8/9, just that he initially wanted 7. [21:25] ok [21:25] rickspencer3: Do you know if Mark has expressed a strong opinion on this particular bikeshed? [21:26] cjwatson, I do not know [21:26] OK. It sounds like 9 is a good common position, then [21:26] * xnox o/ [21:26] * micahg apologizes, but has to go [21:27] xnox: ? [21:27] I'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] if 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] But "S" will be out before then. [21:27] xnox: That's... What Scott said. [21:28] xnox, people are forced to upgrade [21:28] ok, seems like we can put 9 months to a vote [21:28] xnox: we're also discussing allowing upgrading by more than a single release [21:28] quantal support is probably a separate topic for at least two reasons, but ... what stgraber said [21:28] (And leads to another discussion topic, where I think we need to support better upgrade paths) [21:28] stgraber: ok. [21:29] mdz: 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] #vote Reduce maintenance period for regular (non-LTS) Ubuntu releases from 18 months to 9 months (starting with release TBD) [21:29] Please vote on: Reduce maintenance period for regular (non-LTS) Ubuntu releases from 18 months to 9 months (starting with release TBD) [21:29] Public 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] stgraber, ;-) [21:29] mdz: that answers it ;) [21:29] +1 [21:29] +1 received from stgraber [21:29] +1 [21:29] +1 received from mdz [21:29] +1 [21:29] +1 received from cjwatson [21:30] we're missing kees, pitti and soren, yes? [21:30] so that's all TB members present? [21:30] Unfortunately narrow quorum for such an important topic [21:31] we can ask for comments/votes by email as well [21:31] if you want [21:31] I can pretend to be kees. [21:31] xchat agrees, you are equally red colored ... [21:31] a discussion about quorum should ideally have preceded the start of a vote [21:32] #endvote [21:32] Voting ended on: Reduce maintenance period for regular (non-LTS) Ubuntu releases from 18 months to 9 months (starting with release TBD) [21:32] Votes for:3 Votes against:0 Abstentions:0 [21:32] Motion carried [21:32] Sorry, didn't mean to derail [21:32] * cjwatson looks at the mails from the relevant people [21:32] I'm comfortable with meeting quorum on this particular subtopic [21:32] kees expressed support for truncating the support cycle [21:32] So did soren and pitti [21:32] OK [21:33] the next topic should probably be when to make the change effective [21:33] #subtopic effective date for new maintenance period for regular releases [21:33] what are the main options? [21:33] s/effective date/effective release/ [21:34] fair enough [21:34] The former being somewhat ambiguous as to what it will apply to. [21:34] I guess the main options are 12.10, 13.04, later [21:34] ^ [21:35] I thought we'd essentially disposed of that part of the discussion above, but as you like :) [21:35] 13.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] 12.10 doesn't seem workable for reasons discussed above, i.e. breaking promises to users retroactively [21:35] It phases in effort savings over time rather than cutting things off immediately, but that's life, I think [21:35] "Maintenance updates will be provided for Ubuntu 12.10 for 18 months, through April 2014." [21:36] Well, "immediately" would in fact be at minimum four months from now in any event [21:36] (That being 12.10 + 9 months) [21:36] I haven't heard a compelling reason why we should go back on that promise [21:36] how about 13.04? any concerns to discuss there? [21:36] No, I agree. It's an option, and we are right to consider it, but I think we're also right to reject it [21:36] Ideally this would kick in at the start of an LTS cycle, but that's a long time from now. [21:37] right, I don't think we should change anything we already released. Now the question is 13.04 vs 13.10. [21:37] ScottK: What we were discussing in #-release should likely cover the scariness of this happening between LTSen. [21:37] yes, that seems a lot to ask, especially if the goal is to help focus limited attention and resources sooner is much better than later [21:37] infinity: Agreed. [21:38] * 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:39] so 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 sooner [21:39] I 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] unless there's a specific reason to prefer 13.10, that seems like enough of a tiebreaker to me [21:39] right, 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:40] From the discussion I think we can just have an up/down vote on 13.40. [21:40] 13.04. [21:40] I think 14.10 is right out; if that's the fastest we can move as a project then we are doomed :-) [21:40] cjwatson, agreed [21:40] :-) [21:40] now with the upgrade changes being discussed, I'm happy to do that with 13.04 [21:40] #vote Implement the above change to the maintenance schedule effective in 13.04 and later [21:41] Please vote on: Implement the above change to the maintenance schedule effective in 13.04 and later [21:41] Public 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] +1 [21:41] +1 received from mdz [21:41] +1 [21:41] +1 received from stgraber [21:41] +1 [21:41] +1 received from cjwatson [21:42] #endvote [21:42] Voting ended on: Implement the above change to the maintenance schedule effective in 13.04 and later [21:42] Votes for:3 Votes against:0 Abstentions:0 [21:42] Motion carried [21:42] I'm looking at #3 on https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html [21:42] it doesn't seem like there's much substance to it [21:42] just a "designation" [21:42] is there any practical impact to this part of the proposal? [21:42] Well [21:43] As stated it implies having an unstable series, which is quite a big deal operationally :) [21:43] The second half of it is actually a fairly large technical snafu hidden in a quick aside. [21:43] Sorry, not unstable, I mean a perpetual testing [21:43] And given how quickly we freeze/release, I'm not sure it's worth it. [21:43] cjwatson, oh? [21:43] hmm [21:44] We could perhaps meet the request by having an alias [21:44] We've already been working to compress the FF->release window, etc. [21:44] I actually always wondered why we never did suite aliasing, and I think the answer is "inertia" [21:44] cjwatson: Oh, sure, we could absolutely do Debian-style symlink aliases. [21:44] But having a dists/development -> raring (at the current time) symlink wouldn't be that big a deal [21:44] we didn't do it because we didn't want the inter-release upgrade behavior that Debian had [21:44] cjwatson: That's much more lightweight than what I assumed was meant here. [21:45] cjwatson, yeah, that's what I assumed this would entail - a symlink which always pointed to the "rolling release" [21:45] mdz: You'd agree that if we only alias "development", but not "stable", etc, then we don't have the Debian problem? [21:45] whether that's an eternal suite or one which changes sometimes [21:45] infinity: I may be being presumptuous, but I had the impression Mark's proposal was fungible in terms of exact implementation [21:45] infinity, yes [21:45] I'd be all for that. [21:45] Then it's a bikeshed about the name which we don't need to have here [21:45] I read it as a heavyweight "do development in something sid-like, fork for release, repeat". [21:46] the proposal asks the TB to evaluate whether that's a good idea [21:46] That said, that doesn't answer the question of PPAs easily building for just the "edge" release [21:46] I'd be comfortable delegating that to the people running the archive [21:46] 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:46] (the implementation) [21:46] stgraber: As it stands it's not possible - it causes madness in the implementation [21:46] with a goal of making it possible to stay on the rolling release without explicit intervention from the user [21:47] stgraber: Soyuz can't deal with two active releases. [21:47] and madness for doko perhaps :) [21:47] stgraber: That's likely a solvable problem, but not a solved one currently. [21:47] The problem I have with it is actually more fundamental than the implementation [21:47] cjwatson, do tell [21:47] I 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 release [21:47] It also, of course, sucks resources from the freeze and release. [21:47] cjwatson: Jinx. [21:47] ++ [21:48] We've got permission to open backports pre-release for stuff people HAVE to have. [21:48] Which 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 exist [21:48] (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] yeah, 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:49] Anyway, I don't think this stops us having a dev -> whatever symlink [21:49] cjwatson, hmm, maybe I'm misreading this [21:49] So. Back to the symlink topic. That doesn't solve Mark's magical PPA that always targets devel strawman. [21:49] but it wasn't implicit to me that this proposal meant changing anything in terms of the freeze [21:49] I hear we have a release sprint at some point with the LP guys; perhaps we should put this on the table for that [21:49] mdz: That was Colin and I responding to Stephane. [21:49] mdz: It didn't. I was responding specifically to stgraber's comment. [21:49] 21:46 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] just making it possible to stay on the newest/development release continuously [21:49] ok [21:50]