=== pangolin is now known as IdleOne === IdleOne is now known as Guest52467 === smb` is now known as smb === pangolin is now known as Guest94195 === Guest94195 is now known as IdleOne [14:59] * skaet waves [14:59] hello [14:59] hello! [15:00] hi [15:00] o/ [15:00] hi! [15:00] #startmeeting [15:00] Meeting started Fri Jun 22 15:00:39 2012 UTC. The chair is skaet. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [15:00] 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 [15:00] * stgraber waves [15:00] o/ [15:01] welcome. :) [15:01] Upcoming dates: [15:01] 2012/06/25 - Alpha 2 candidate images start [15:01] 2012/06/28 - Alpha 2 [15:01] 2012/07/05 - DebianImportFreeze [15:01] . [15:01] Work Items: [15:01] 2012/06/22 - 2926 (was 2627 last week) : trending behind where we should be on burndown line. [15:01] Please help get us back where we should be by making sure https://launchpad.net/~/+upcomingwork is up to date for your tasks. [15:01] . [15:01] Bugs: [15:01] Quantal: http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html [15:02] 12.04.1:http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html [15:02] . [15:02] Weekly Status Received: [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001401.html- ogasawara (use email for questions) [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001412.html - hw cert: brendand [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001420.html - lubuntu: gilir [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001422.html - security: mdeslaurs [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001432.html - desktop: seb128: [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001433.html - manual testing: balloons [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001434.html - ubuntu one: joshuahoover [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001435.html - edubuntu :stgraber [15:02] ** 2100 UTC - due time ^ Thank you to those who submitted on time ** [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001440.html - linaro: fabo [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001441.html - Kubuntu: Riddell [15:02] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001442.html - Unity: popey [15:03] I've still missed a few late incoming reports, please feel free to paste them in to the record, as we go along. [15:03] apologies Server was a little late @ [15:03] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001449.html [15:03] .. [15:03] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001398.html - astraljava [15:03] :) thanks arosales. :) [15:03] .. [15:03] and astraljava, :) [15:04] foundations too ... [15:04] QA https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001445.html [15:04] https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001450.html [15:04] Thanks guys! [15:04] hi [15:04] ok, will try to get through them as well, while we go through the Q&A part, but may need to be following up on email list after. [15:05] #topic Comments and Questions. === meetingology changed the topic of #ubuntu-meeting to: Comments and Questions. [15:05] please 'o/' when you have a new question. '..' when you're finished with the current topic under discussion. [15:06] status.ubuntu.com trendlines were reset last friday. If you spot any that were missed, please ping me after the meeting directly. [15:06] * skaet marks that action done ;) [15:06] To help people have visibility into the work item tasks and bugs they're assigned to, there is now a new launchpad view available. try: https://launchpad.net/~/+upcomingwork Thank you to the linaro team for getting this change in launchpad! if you don't see a workitem in the list, please talk to the blueprint approver and make sure the blueprint is assigned to a milestone. [15:07] .. [15:07] \o/ [15:07] :) [15:07] +1 [15:08] and some other news, that's going to be of interest as we head into A2 ... [15:08] The bug workflow we'll be trying out this cycle has been sorted out. We'll be using the tag "rls-q-incoming" to signal a bug needs to be looked at by the development teams for inclusion in the release. [15:08] These nominated incoming bugs can be found: http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-incoming-bug-tasks.html. Goal here is to keep this report as empty as possible. [15:08] The bugs that the development teams are committed to fixing can be found here: [15:08] http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html [15:08] (no incoming tag, and targetted to quantal gets a bug on this list) [15:08] For those bugs targetted to quantal that there isn't a plan in place to fix, the tag 'rls-q-notfixing' will be on the bug, and they'll show up in: [15:08] http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-notfixing-bug-tasks.html [15:08] Questions? [15:09] .. [15:10] alpha 2 next week? [15:10] please feel free to start a discussion about any questions on it, in #ubuntu-release. [15:10] Riddell, yup A2 is next week. [15:10] who's the tech driver? [15:11] 2012/06/25 - Alpha 2 candidate images start [15:11] 2012/06/28 - Alpha 2 [15:11] Riddell, Daviey is tech driver this time around [15:11] tsk that's what I get for being 2 minutes late [15:11] :) [15:12] Riddell, you ok with using the bug flow as outlined for Kubuntu? [15:13] We still need a mechanism, so that the flavors and upstream projects are able to denote which bugs they are committing to fix, if they can't assign to the series directly. For Kubuntu, Edubuntu I think this is not an issue. For Unity, Lubuntu, Mythbuntu, Ubuntu Studio, Xubuntu - you ok with using a tag? [15:13] gilir, scott-work, astraljava, superm1, popey any preferences or alternate suggestions? [15:13] skaet: rls-q-tracking-bug-tasks.html ? I need to read up on it [15:13] Riddell, fair enough. [15:13] #ubuntu-release for discussion after the meeting then. [15:13] Tags are fine with me. [15:13] .. [15:14] nope [15:14] yeah in Edubuntu it works pretty much assigning edubuntu-dev and a milestone to indicate a commitment to fix it. [15:14] s/pretty much/pretty well/g [15:14] we tag with kubuntu and milestone it generally [15:15] astraljava, popey, ok - I'll come up with a proposal and circulate it via the ubuntu-release mail list. [15:15] Riddell, so we'd be asking you to series target it, in addition. [15:15] skaet: makes sense [15:15] thanks! [15:16] we can figure out the plan there. [15:16] .. [15:16] o/ [15:17] go brendand [15:17] i'd just like to mention that this bug is causing us a bit of pain at the moment: https://launchpad.net/bugs/1013843 [15:17] Launchpad bug 1013843 in casper (Ubuntu Quantal) "resolv.conf empty when doing PXE installations" [Undecided,New] [15:18] brendand: it's on my todo [15:19] stgraber, thanks [15:19] .. [15:19] and going on to the other news that's emerging.... [15:20] stgraber - can you give an overview of the changes with the new version of ISO tracker? what should folks expect? [15:20] So, I've spent quite a bit of time over the past month or so implementing some new features in the QA tracker. [15:20] The biggest change is the introduction of the testcase management changes, this introduces the concept of testsuites into the tracker as well as testcase revisions. [15:20] The actual text of the testcases is now stored in the tracker including any history. Test results are linked to a specific revision of a testcase. [15:20] Testcases are now put into testsuites that can then be linked to products on a per-series basis. A testcase can be in multiple testsuites and products can have multiple linked testsuites per series. [15:20] That's for the core testcase management stuff. [15:20] [15:20] On top of that, the UI was slightly improved, showing the past reported bugs (on a per milestone, product and testcase basis) in the result reporting form, making it easier for tests to pick previous bugs. [15:20] It's also now possible to add bug reporting instructions for every product. A link was also added to the various testcases to report a bug against a testcase and a similar link exists in the main menu to report a bug against the tracker. [15:20] A new build status "ready" has been introduced, letting the product managers sign off on a specific build. [15:20] [15:20] ACLs have been improved, introduction a new "testcase management" role allowing members to update testsuites and testcases. [15:20] On top of that, a new "product management" role has also been added, allowing us to delegate sign-off, result management and build management on a per-product basis (useful for flavours). [15:21] [15:21] And less visible but still good for people involved with that, the DB schema was updated to allow for "default" download links, avoiding the current duplication (all the links currently had to be copied for every series). [15:21] It's also now possible to show a custom testcase ID instead of the raw database record ID (feature requested by QA). [15:21] The API also had to suffer a minor breakage because of the new testcase management structure, please make sure to update python-qatracker and change your .get_testcases() calls to include the milestone as the first argument. [15:21] [15:21] If you have any question, feedback or bug report, please get in touch in #ubuntu-iso-tracker. [15:21] .. [15:21] * Daviey notes that stgraber types very fast. [15:21] Thanks stgraber! :) [15:21] yes, stgraber thank you very much! [15:22] Daviey, he knew that question would come and prepared a paste :) [15:22] (i bet) [15:22] on to the other news that's going to be relevant for A2... ;) [15:22] o/ [15:22] balloons - can you give an overview of the new test case format, and what we're doing on standardizing and reviewing the test cases for rest of the cycle? [15:22] sure :-) [15:22] * skaet will get back to stgraber after balloons [15:23] The new testcase format is the same as what the qa community decided upon last December when we first undertook the updating of testcases. Simply put for every action taken, there is an expected result. Each step should have those two paired together. [15:23] We're migrating all testcases and consolidating them into the tracker. Once migrated a new team is being organized to help maintain the testcases and manage https://launchpad.net/~ubuntu-testcase. People not on this team will still be able to provide feedback and submit fixes or new tests by filing a bug against the ubuntu qa website. [15:23] Finally, I'm undertaking a review of testcases used (aka, what do we need to be mandatory testcases for each release) and will be contacting some of you folks for feedback. The idea is to review what we are testing and add/remove/modify testcases to ensure out tests are serving the purpose of assuring the image is ready for release :-) [15:25] ..? [15:25] balloons: Server is very keen for some support improving out mandatory test cases, looking forward to disucssing further. [15:25] sorry yes [15:25] ... [15:26] Thanks balloons! :) [15:26] stgraber, go ahead [15:26] so I just wanted to say that for alpha-2 we'll mostly be running in "legacy" mode for the testcases on the tracker [15:26] o/ [15:27] with maybe one product using the new format. The others will simply link to the good old testcase on the wiki [15:27] as we transition to the new testcases and testsuites, these will hopefully disappear and be there just for archiving reasons by the end of the cycle [15:28] you can easily spot these as they are in testsuites named after their respecitve products and with "legacy" in their name [15:28] .. [15:28] thanks stgraber. :) [15:28] go ahead ScottK [15:28] Would it make sense to make ~core-dev (or maybe ~ubuntu-dev) a member of ~ubuntu-testcase (and how much more email would that mean I get)? [15:28] .. [15:29] o/ [15:29] I think that's probably directed to you balloons, [15:29] go ahead [15:29] ;-) [15:30] ScottK, I'm not sure who is all on the core-dev team. Basically, I want folks who join the team to help maintain the testcases going forward (so they don't become outdated or broken); so there's a little responsibility to joining [15:31] I don't want to restrict it however, so if the folks on core-dev can undertake the responsibility, let's add them :-) [15:31] balloons, any feel for the email traffic likely? [15:31] .. [15:32] I think that collectively you'll get a few that want to adjust things now and then. [15:32] skaet, umm no no idea on the email traffic.. I don't see me sending mail directly to the team very often [15:32] or anyone else only contacting the team [15:32] core-dev people tend to get grumpy when there are things they can't do a drive-by commit/fix to. [15:32] everything occurring should more or less be public [15:32] and you can find them here btw https://launchpad.net/~ubuntu-core-dev/+members#active [15:32] :) [15:33] ScottK, yes.. having more people looking after both the common testcases, and the flavor specific stuff is good [15:33] we can all benefit from people making sure our tests are up-to-date and easy to follow and use [15:34] ogra_, ahh core-devs.. fun :-) Thanks [15:35] infinity: +1. "Can't do it myself -> later." [15:35] balloons: generally core-devs all can upload and fix the testcase produced bugs, so they might as well fix/expand the test-cases to prevent certain bugs reoccurring or test something new. [15:36] .. [15:36] or adding || true to the test cases to make sure their uploads pass. [15:36] .. [15:36] xnox, hmm.. yes, makes sense to not prevent them from ensuring testing occurs [15:36] .. [15:37] * skaet doesn't see any hands queued up, so, on to more of her questions ;) [15:37] seb128, from community testing and QA report this week - https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1005677 can you look into it? possible to fix by A2? [15:37] Launchpad bug 1005677 in qt4-x11 (Ubuntu) "Re-emergence of "Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)'"" [High,Confirmed] [15:38] skaet, I will see what we can do, we don't have qt maintainers or people knowing the code much though [15:38] maybe the Kubuntu team can help? [15:39] ScottK, Riddell, ^ ? [15:39] Maybe even fabo could help. [15:39] qt's gtk widget style is probably something nobody in ubuntu has much experience with [15:39] just reading the bug, I will ask ken to have a look if it's due to the scollbar code [15:40] .. [15:41] thanks seb128 [15:41] Riddell, ScottK - which images will Kubuntu be putting out with A2? [15:41] as many as we can [15:41] DVD is gone, so not that one. [15:42] i386/amd64 desktop alternate and arm omap4 I hope, no kubuntu active [15:42] Thanks. [15:42] skaet, btw shouldn't those sort of bugs be rls-q-incoming tagged? I reviewed the list before the meeting, I would have noticed it earlier if it had been tagged (or team assigned) [15:42] was wondering about kubuntu active. [15:42] seb128, yes it should be tagged that way by the teams gong forward [15:42] :) [15:43] ;-) [15:43] thanks [15:43] however, we needed the communication of the plan before expecting folks to know what to do ;) [15:43] .. [15:43] Daviey, are you continuing with only amd64 for ubuntu server for A2? [15:44] skaet: that is th plan [15:44] o/ [15:44] thanks Daviey. [15:44] go ScottK [15:44] Is the intent only to release amd64 for server or this that just for now? [15:45] .. [15:45] Daviey: ^^ [15:45] ScottK: the current plan is to only realease and amd64 large iso for final. [15:45] ScottK: mini.iso, and netboot still fully supported. [15:45] Sigh. OK. Thanks. [15:45] ScottK: A1 didn't have any negative feedback, but still building and reviewing feedback as it goes. [15:46] ScottK: Why sigh? [15:46] I have 32bit only hardware. [15:46] ScottK: installing from mini/net are usually more pleasant experiences anyway. :P [15:46] Heh. [15:46] ScottK: which hardware? [15:46] ScottK: Unless you're the only man in the world whose network is slower than a CD or USB key. [15:46] infinity: Probably not. [15:47] ScottK: part of the reason to 'just do it' was to flush out server hardware which is 32bit only. [15:47] Daviey: A combination of older Intel Atom processors and Pentium IIIs. [15:47] ScottK: Alpha 1 yielded no feedback. [15:47] Right, because I don't reinstall servers for Alpha 1. [15:48] ScottK: And you use the large iso image to install them? [15:48] I'm also running quite a bunch of Atom based routers/lxc hosts that are sadly i386 only, but well, they don't have cdrom drives anyway so I'm not really affected :) [15:48] I did last time I did it. [15:48] I tend to just upgrade them. [15:48] Daviey: what about the massive thread on the u-d about switching default iso download link from i386->amd64 for desktops. All the retired desktops... become servers wanting a reinstall. [15:48] ScottK: do you think many users will be impacted for new installs? [15:49] Daviey: Not installs of new hardware, but if they have a problem and have to reinstall something on existing hardware. [15:49] should we move that discussion to lists maybe? [15:49] it probably interest people out of this meeting ;-) [15:49] Okay, i'll take the action of being verbal on devel [15:49] .. [15:49] astraljava, will your team be participating in A2? which images if so? [15:50] Fine with me. [15:50] o/ [15:51] * skaet not sure if astraljava is still around.... [15:51] go ahead arosales [15:51] server cloud images will still have i386 for this cycle, however we would like to move to only amd64 eventually too based on only having amd64 server iso images. [15:51] .. [15:51] popey, for quantal between now and next monday (A2) is there anything planned to land? Are there any new features in the drops so far that need to get explained in the technical overview? [15:52] Sorry, I'm here. Yep, Xubuntu will participate in Alpha-2. Images: alternates and desktops, both archs. [15:52] .. [15:52] thanks astraljava. :) [15:52] arosales: There's actually more agument for cloud images having a 32-bit option than server ISOs. [15:53] (Cause lots of people do 32-on-64 for workloads with small memory footprints) [15:53] skaet, did you have any question left for me? I've something planned at 6pm (i.e in 5 minutes) and need to run [15:53] o/ [15:53] skaet, afaik nothing planned for unity stack out for SRUs [15:53] correct [15:53] out of SRUs [15:53] thanks seb128, popey [15:53] .. [15:53] * ogra_ jumps [15:53] have a nice evening seb128, those were the main ones. [15:53] infinity: main concern there is foot print size? [15:54] for you. [15:54] skaet, thanks, I will read scrollback and list if there is any question [15:54] .. [15:54] go stgraber [15:55] arosales: Not the install footprint, but the in-memory footprint, yes. [15:55] so, just wanted to warn that I'm currently preparing a network stack update (ifupdown, resolvconf, isc-dhcp, possibly vlan, bridge-utils and ifenslave-2.6). Debian has been doing some weird things around these lately so it's a bit harder than usual (involves a lot of breaks/replaces and moving init jobs around). I'll have a PPA ready for testing soonish [15:56] I don't expect these to land for alpha-2 but they might hit -proposed next week to be released in the release pocket post-alpha [15:56] thanks for the heads up. [15:56] I'll try and go through the bugs for these packages again before upload, if you have any current issue with these packages, please ping. [15:56] .. [15:57] Could the release team members present please raise their hand? Want to see if there is quorum for the milestone/freeze discussion we were thinking about on #ubuntu-release yesterday. and if we want to go past the hour? [15:57] infinity: thanks for the feedback. I'll get in touch with you to see how large of an impact this would be. Some newer clouds are only offering 64 bit images .. [15:57] o/ [15:57] o/ [15:57] o/ [15:57] skaet o/ ;) [15:58] skaet: THat was an "I'm here", not a "I think we should extend the meeting". [15:58] extending the meeting needs both arms raised, right ? [15:58] :) [15:58] skaet, i need to scoot and do some compiz SRU work.. can I please be excused? :) [15:58] ScottK and Riddell are around, but I'm not seeing signs of Laney. [15:58] Laney's around. [15:58] thanks popey for joining us. [15:59] o/ [15:59] greetings [15:59] skaet, sil2100 can answer if you have any questions for me [15:59] I thought this meeting was from 1700-1800 BST [15:59] UTC [15:59] so just checked in to see that it had been going for an hour [15:59] the horror! [15:59] :) [15:59] o/ [16:00] slangasek, NCommander were talking in other channels not too long ago, they might be around too [16:00] I think we're close enough to quorum, any one feel strongly scheduling something different, or continue on now. [16:00] * NCommander is around === pangolin is now known as Guest77463 [16:01] this is fine === Guest77463 is now known as IdleOne [16:01] infinity, Laney - correct me if I'm wrong, but I think the open question is What prerequisites need to be in place before we can consider dropping the milestones for the alpha part of the release? [16:01] The original proposal was around dropping the 'freeze' part of the milestones, and then the question of dropping milestones altogether arose and kind of took over. [16:01] doesnt that depend on the infrastructure the QA team will build up in early august ? [16:02] (else we cant do any automated arm testing afaik) [16:02] skaet: Well, we need a cultural shift to more consistent/regular testing (PlusOneQA, to go with PlusOneMaint, if you will), and we almost certainly need the testing-style migration in place, with all uploads going to proposed. [16:02] ogra_: Automation is important, but probably not related to this. [16:03] k [16:03] i thought it was a requirement [16:03] ogra_: It's the culture of "we only manually test right before milestones, then panic" that needs fixing. [16:03] +1 on that. :) [16:03] anyone else have thoughts to add to infinity's? [16:04] Laney: I think dropping the freeze and dropping the milestones are tightly coupled. I don't think you can effectively do one without the other. [16:04] Anyhow, as I see it, "dropping milestones" isn't something we should be looking to do, it's something we should be looking at as a side-effect. [16:04] it's hard enough to get people to test for milestones, I can't see how to get people to test for non-milestones and be able to track the bugs in any meaningful way [16:04] As in, once our QA processes are more sane, milestones will almost "obviously" become a complete waste of time. [16:04] so set a milestone for your people [16:04] I mentioned it in some of my e-mails and on IRC but my point of view is that things should be done incrementally, increasing daily testing and implementing -proposed are good first steps [16:05] stgraber, ++ [16:05] we can then look at the results of these changes and discuss the next step for the next cycle [16:05] and + [16:05] ScottK: Possibly true. I don't know what effect the -proposed redirection would have. [16:05] * ogra_ also thinks its way to ruched [16:05] *rushed [16:05] One of the really useful things about milestones for me as an end user is that I know if I test for a milestone and it's a bug that gets tied to the ISO testing, it gets more attention. [16:05] ScottK: That's a process issue. [16:06] I think that if we can show that we are getting enough testing between milestones that the milestones have ceased to be important, then they can fall away. But proving that the testing is happening comes first [16:06] ScottK: A bug found in a daily is just as important as one found during "milestone panic week", and if that's not currently true, that needs to be fixed. [16:06] tumbleweed: That's the right order to look at it. [16:06] and thats why i assumed the automated testing was a req. [16:07] ogra_: We don't have automated testing for ARM at milestone times either. :P [16:07] infinity, nope, i assumed daily testing though [16:07] ogra_: In reality, people think milestones are important because it's when "all the manual testing" happens, which shakes out all the "weird" bugs that automation doesn't see. [16:07] yes [16:07] and i agree with that, you still need the drive by testers [16:08] and as i wrote in my mail we mostly get them *after* the milestone due to the announcement [16:08] So, yeah. I think the obvious first goal is decoupling that, and having "all the manual testing" happen "all the time". And if people feel that bugs reported at milestones are getting an inflated priority, we need to fix that. [16:08] ScottK: doesn't this proposal mean that Kubuntu for example can have kubuntu specific milestones in sync with landing KDE releases to test those in meaningful way. [16:08] If I find a scary bug 2 weeks before an Alpha, or two days after, it's just as critical. [16:08] Error: Launchpad bug 2 could not be found [16:08] heh [16:08] xnox: Not really. [16:08] xnox, +1. I like the idea of having focused efforts of testing around things that make sense [16:08] ogra_: in which case, we make the best use of the drive by testers if we spend a bit of time polishing the image [16:09] tumbleweed, well, or through other events ... thats why i asked if there was anythin planned [16:09] balloons: That's what we (Xubuntu) was hoping for, as well. [16:09] were [16:09] tumbleweed: Our images 3 days after milestones are often better than the milestone. :P [16:09] :) [16:09] tumbleweed: But people all rush out to test the milestone, not the next daily, and report dupes of all the bugs in the release notes. [16:09] I pretty firmly disagree with dropping of freeze and/or milestones.. but seems i am a minority [16:09] (Yes, this actually happens) [16:09] Daviey: I agree with you. [16:10] asdo I, but I've reclused myself from this topic and its dusciussion [16:10] infinity, tumbleweed case in point. I used the daily after alpha1 to install. it had lots of fixes in it that alpha 1 did not :-) [16:10] One would hope that quality is increasing as we go on. [16:10] * xnox sees that freezes and milestones is the whole point of time based release management which actually drives the stability to land on time. [16:10] Anyhow, I think there's a horse and carriage issue here, where people immediately jump to the conclusion without the interim. [16:10] xnox: +1! [16:11] Anyway. [16:11] xnox: Different flavors can't do milestones whenever they want both because (at least for now) parts of the archive need freezing and Canonical needs to commit resources to ISO building/releasing. [16:11] by dropping milestones, it's effectively switching to a rolling release schedule [16:11] NCommander: reclused/recused. [16:11] Don't frame this as "don't take away my milestones, it'll kill my testing", frame this as "removing milestones some day is an interesting goal, if we can improve our testing processes beforehand". [16:11] * NCommander coughs [16:11] balloons, but you were lucky that no installer changes landed that broke installability [16:11] I wanted us to have this discussion so that we, as the release team, can present "our opinion". [16:11] infinity, balloons and jibel's reports each week has the key bugs they're finding and worried about, maybe a good first step is making sure they're sorted out by the development teams before the milestone week? [16:12] ogra_: If we're breaking installability, we need to fix that too. :P [16:12] infinity, sure, not saying we shouldnt [16:12] One of the key things that milestones provide, is a genuine target for a feature or bugfix. Rolling fake milestones make it less urgent, and therefore will slow velocity. Which is a big deal. [16:12] but having a daily bootable and installable is a matter of luck currently [16:12] infinity: Milestones have non-technical benefits as well. I'm not sure that on the whole it's a good goal. I think not having to freeze for a milestone might be a good future goal. [16:13] I would be in favor of: shortening the release week, and introducing gradually more frequent freezes and more frequent milestones. By a day or two. Then we will find the right cadence in a sliding manner. [16:13] ogra_: I see this discussion as a natural extension to PlusOneMaint. If we're pushing for an archive that's always consistent (PlusOneMaint's current top mandate), then we need a PlusOneQA to go with it that makes sure dailies are actually not crap, after the POM people have made sure dailies can exist. [16:13] infinity, right [16:13] We can invite the community QA team to implement their desired process, and then evaluate how successful it is. And maybe experiment with not freezing for a milestone once we have the proposed infrastructure in place. [16:13] infinity: I understood the 'rolling miletsone' would be a two week cadence for manual testing [16:14] Laney: Community QA and their process only affects Ubuntu images. [16:14] Daviey: That seems to be a first cut attempt from balloons' team. [16:14] Daviey: That's hardly set in stone. [16:14] They've made that very clear, so it's not sufficient by definition. [16:14] Laney: do you want to gauge release team votes to indicate excitement for this change ? [16:14] ScottK: Yeah. I think that's unfortunate and we need to work out how to fix that too. [16:14] Daviey: Honestly, I'd rather see UE teams take an hour once a week to just spin up some ISOs. Rotate that between teams, and you get coverage over the whole week. Bam, daily testing. [16:15] infinity: and there will be daily testing and no daily development?! [16:15] ScottK: To be fair, while having daily testing of everything would be awesome, even Ubuntu testing is still exercising bits other flavours care about. Just not all the bits. [16:16] xnox, for 1h [16:16] of one team member [16:16] infinity: That's true. [16:16] xnox: If making your 40 hour week a 39 hour week halts your development, we have some odd problems we need to discuss with vorlon. ;) [16:16] *grin* [16:16] infinity: i don't disagree with that at all.. And whilst we don't do full manual mandatory testing by hand (it is fully automated).. i dont think a week passes without us doing manual installs. [16:16] ogra_: RAID install takes longer than 1h [16:16] xnox, arm live image installs too [16:17] xnox: Not one hour that you have to stare at it, surely. [16:17] I'm reasonably happy with the daily RAID testing to not make that a weekly by-hand test [16:17] * infinity image tests in the background while, like, working. [16:17] xnox, we should never enable raid on arm live images i conclude :) [16:17] Turns out computers are pretty good at doing stuff even when I'm not staring at them. [16:17] infinity: Me too, but not on anything that requires sustained concentration. [16:17] ogra_: oh but we are =) anyway this is off topic [16:18] So.. there seems to be no measure of peoples view on this? [16:18] ScottK: Oh, I sometimes get engrossed, and then notice I have a test install that's been patiently waiting on input for, like, 3 days. :) [16:18] Heh. [16:19] I don't think anyone is opposed to the idea of tools and processes to make it possible to not freeze during a milestone. [16:19] No change is going to happen for A2. We'll follow the same pattern for A2 as we used for A1 once we start spinning up the images (asking folks to upload to -proposed). We should be prioritizing fixing the issues that our EXISTING testing is finding, and work on strengthening up the infrastructure. [16:19] I don't think anyone is opposed to encouraging additional testing between milestones so there's less surpise. [16:19] is that a reasonable summary ^ ? [16:19] I'd add "culture" to your infrastructure comment, but sure. [16:20] infinity: Yes. [16:20] infinity, agreed. :) [16:20] It's not all about tools. Tools don't magically change what people do, or why they do it, it's about message. [16:20] skaet: For Alpha 2 I think that's right. [16:21] I would like to make it clear that any changes to the release process must bring the flavours along. [16:21] * Daviey has to go now, but i'd like it noted that i am not keen on these changes. [16:21]