15:00:39 <skaet> #startmeeting
15:00:39 <meetingology> 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:39 <meetingology> 
15:00:39 <meetingology> 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:46 * stgraber waves
15:00:50 <popey> o/
15:01:43 <skaet> welcome.  :)
15:01:48 <skaet> Upcoming dates:
15:01:48 <skaet> 2012/06/25 - Alpha 2 candidate images start
15:01:48 <skaet> 2012/06/28 - Alpha 2
15:01:48 <skaet> 2012/07/05 - DebianImportFreeze
15:01:48 <skaet> .
15:01:48 <skaet> Work Items:
15:01:50 <skaet> 2012/06/22 - 2926 (was 2627 last week) : trending behind where we should be on burndown line.
15:01:52 <skaet> 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:55 <skaet> .
15:01:57 <skaet> Bugs:
15:01:59 <skaet> Quantal: http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html
15:02:01 <skaet> 12.04.1:http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html
15:02:03 <skaet> .
15:02:05 <skaet> Weekly Status Received:
15:02:13 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001401.html- ogasawara (use email for questions)
15:02:14 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001412.html - hw cert: brendand
15:02:14 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001420.html - lubuntu: gilir
15:02:16 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001422.html - security: mdeslaurs
15:02:18 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001432.html - desktop: seb128:
15:02:20 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001433.html - manual testing: balloons
15:02:22 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001434.html - ubuntu one: joshuahoover
15:02:24 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001435.html - edubuntu :stgraber
15:02:26 <skaet> ** 2100 UTC - due time ^ Thank you to those who submitted on time **
15:02:28 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001440.html - linaro: fabo
15:02:30 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001441.html - Kubuntu: Riddell
15:02:32 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001442.html - Unity: popey
15:03:24 <skaet> 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:32 <arosales> apologies Server was a little late @
15:03:32 <arosales> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001449.html
15:03:44 <arosales> ..
15:03:46 <astraljava> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001398.html - astraljava
15:03:46 <skaet> :)  thanks arosales.  :)
15:03:49 <astraljava> ..
15:03:57 <skaet> and astraljava,  :)
15:04:03 <ogra_> foundations too ...
15:04:24 <jibel> QA https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001445.html
15:04:26 <ogra_> https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001450.html
15:04:31 <skaet> Thanks guys!
15:04:43 <Riddell> hi
15:04:57 <skaet> 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:16 <skaet> #topic  Comments and Questions.
15:05:46 <skaet> please 'o/' when you have a new question.   '..' when you're finished with the current topic under discussion.
15:06:03 <skaet> status.ubuntu.com trendlines were reset last friday.  If you spot any that were missed,  please ping me after the meeting directly.
15:06:28 * skaet marks that action done ;)
15:06:48 <skaet> 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:08 <skaet> ..
15:07:08 <Daviey> \o/
15:07:20 <skaet> :)
15:07:28 <arosales> +1
15:08:23 <skaet> and some other news,  that's going to be of interest as we head into A2 ...
15:08:40 <skaet> 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:40 <skaet> 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:40 <skaet> The bugs that the development teams are committed to fixing can be found here:
15:08:40 <skaet> http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html
15:08:42 <skaet> (no incoming tag, and targetted to quantal gets a bug on this list)
15:08:44 <skaet> 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:47 <skaet> http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-notfixing-bug-tasks.html
15:08:49 <skaet> Questions?
15:09:09 <skaet> ..
15:10:30 <Riddell> alpha 2 next week?
15:10:33 <skaet> please feel free to start a discussion about any questions on it,  in #ubuntu-release.
15:10:43 <skaet> Riddell,  yup A2 is next week.
15:10:58 <Riddell> who's the tech driver?
15:11:05 <skaet> <skaet> 2012/06/25 - Alpha 2 candidate images start
15:11:05 <skaet> <skaet> 2012/06/28 - Alpha 2
15:11:24 <skaet> Riddell,  Daviey is tech driver this time around
15:11:24 <Riddell> tsk that's what I get for being 2 minutes late
15:11:30 <skaet> :)
15:12:17 <skaet> Riddell, you ok with using the bug flow as outlined for Kubuntu?
15:13:00 <skaet> 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:00 <skaet> gilir, scott-work, astraljava, superm1, popey any preferences or alternate suggestions?
15:13:06 <Riddell> skaet: rls-q-tracking-bug-tasks.html ?  I need to read up on it
15:13:15 <skaet> Riddell,  fair enough.
15:13:30 <skaet> #ubuntu-release for discussion after the meeting then.
15:13:44 <astraljava> Tags are fine with me.
15:13:46 <astraljava> ..
15:14:13 <popey> nope
15:14:15 <highvoltage> yeah in Edubuntu it works pretty much assigning edubuntu-dev and a milestone to indicate a commitment to fix it.
15:14:24 <highvoltage> s/pretty much/pretty well/g
15:14:57 <Riddell> we tag with kubuntu and milestone it generally
15:15:17 <skaet> astraljava,  popey,  ok - I'll come up with a proposal and circulate it via the ubuntu-release  mail list.
15:15:29 <skaet> Riddell,  so we'd be asking you to series target it,  in addition.
15:15:40 <Riddell> skaet: makes sense
15:15:44 <skaet> thanks!
15:16:11 <skaet> we can figure out the plan there.
15:16:14 <skaet> ..
15:16:56 <brendand> o/
15:17:02 <skaet> go brendand
15:17:44 <brendand> 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:46 <ubottu> Launchpad bug 1013843 in casper (Ubuntu Quantal) "resolv.conf empty when doing PXE installations" [Undecided,New]
15:18:13 <stgraber> brendand: it's on my todo
15:19:02 <brendand> stgraber, thanks
15:19:28 <skaet> ..
15:19:45 <skaet> and going on to the other news that's emerging....
15:20:03 <skaet> stgraber - can you give an overview of the changes with the new version of ISO tracker?  what should folks expect?
15:20:24 <stgraber> 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:27 <stgraber> 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:30 <stgraber> 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:33 <stgraber> 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:37 <stgraber> That's for the core testcase management stuff.
15:20:40 <stgraber> 
15:20:42 <stgraber> 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:46 <stgraber> 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:51 <stgraber> A new build status "ready" has been introduced, letting the product managers sign off on a specific build.
15:20:53 <stgraber> 
15:20:56 <stgraber> ACLs have been improved, introduction a new "testcase management" role allowing members to update testsuites and testcases.
15:20:59 <stgraber> 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:03 <stgraber> 
15:21:05 <stgraber> 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:09 <stgraber> It's also now possible to show a custom testcase ID instead of the raw database record ID (feature requested by QA).
15:21:12 <stgraber> 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:16 <stgraber> 
15:21:19 <stgraber> If you have any question, feedback or bug report, please get in touch in #ubuntu-iso-tracker.
15:21:22 <stgraber> ..
15:21:31 * Daviey notes that stgraber types very fast.
15:21:41 <skaet> Thanks stgraber!  :)
15:21:56 <balloons> yes, stgraber thank you very much!
15:22:09 <ogra_> Daviey, he knew that question would come and prepared a paste :)
15:22:19 <ogra_> (i bet)
15:22:26 <skaet> on to the other news that's going to be relevant for A2...  ;)
15:22:36 <stgraber> o/
15:22:38 <skaet> 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:53 <balloons> sure :-)
15:22:56 * skaet will get back to stgraber after balloons
15:23:00 <balloons> 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:36 <balloons> 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:56 <balloons> 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:32 <skaet> ..?
15:25:36 <Daviey> balloons: Server is very keen for some support improving out mandatory test cases, looking forward to disucssing further.
15:25:51 <balloons> sorry yes
15:25:52 <balloons> ...
15:26:13 <skaet> Thanks balloons!  :)
15:26:30 <skaet> stgraber,  go ahead
15:26:50 <stgraber> 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:51 <ScottK> o/
15:27:06 <stgraber> with maybe one product using the new format. The others will simply link to the good old testcase on the wiki
15:27:39 <stgraber> 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:21 <stgraber> you can easily spot these as they are in testsuites named after their respecitve products and with "legacy" in their name
15:28:25 <stgraber> ..
15:28:37 <skaet> thanks stgraber.  :)
15:28:55 <skaet> go ahead ScottK
15:28:57 <ScottK> 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:58 <ScottK> ..
15:29:13 <balloons> o/
15:29:35 <skaet> I think that's probably directed to you balloons,
15:29:37 <skaet> go ahead
15:29:50 <balloons> ;-)
15:30:54 <balloons> 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:19 <balloons> 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:53 <skaet> balloons,  any feel for the email traffic likely?
15:31:53 <balloons> ..
15:32:01 <ScottK> I think that collectively you'll get a few that want to adjust things now and then.
15:32:27 <balloons> skaet, umm no no idea on the email traffic.. I don't see me sending mail directly to the team very often
15:32:33 <balloons> or anyone else only contacting the team
15:32:36 <infinity> core-dev people tend to get grumpy when there are things they can't do a drive-by commit/fix to.
15:32:43 <balloons> everything occurring should more or less be public
15:32:47 <ogra_> and you can find them here btw https://launchpad.net/~ubuntu-core-dev/+members#active
15:32:49 <ogra_> :)
15:33:10 <balloons> ScottK, yes.. having more people looking after both the common testcases, and the flavor specific stuff is good
15:33:50 <balloons> we can all benefit from people making sure our tests are up-to-date and easy to follow and use
15:34:45 <balloons> ogra_, ahh core-devs.. fun :-) Thanks
15:35:08 <ScottK> infinity: +1.  "Can't do it myself -> later."
15:35:58 <xnox> 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:27 <xnox> ..
15:36:35 <Daviey> or adding || true to the test cases to make sure their uploads pass.
15:36:40 <Daviey> ..
15:36:57 <balloons> xnox, hmm.. yes, makes sense to not prevent them from ensuring testing occurs
15:36:59 <balloons> ..
15:37:37 * skaet doesn't see any hands queued up,  so, on to more of her questions ;)
15:37:56 <skaet> 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:58 <ubottu> 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:46 <seb128> skaet, I will see what we can do, we don't have qt maintainers or people knowing the code much though
15:38:52 <seb128> maybe the Kubuntu team can help?
15:39:02 <skaet> ScottK,  Riddell, ^ ?
15:39:32 <ScottK> Maybe even fabo could help.
15:39:38 <Riddell> qt's gtk widget style is probably something nobody in ubuntu has much experience with
15:39:42 <seb128> just reading the bug, I will ask ken to have a look if it's due to the scollbar code
15:40:36 <seb128> ..
15:41:05 <skaet> thanks seb128
15:41:21 <skaet> Riddell,  ScottK - which images will Kubuntu be putting out with A2?
15:41:35 <Riddell> as many as we can
15:41:49 <ScottK> DVD is gone, so not that one.
15:42:03 <Riddell> i386/amd64 desktop alternate and arm omap4 I hope, no kubuntu active
15:42:16 <skaet> Thanks.
15:42:26 <seb128> 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:37 <skaet> was wondering about kubuntu active.
15:42:55 <skaet> seb128, yes it should be tagged that way by the teams gong forward
15:42:59 <skaet> :)
15:43:09 <seb128> ;-)
15:43:10 <seb128> thanks
15:43:30 <skaet> however,  we needed the communication of the plan before expecting folks to know what to do ;)
15:43:33 <skaet> ..
15:43:55 <skaet> Daviey,  are you continuing with only amd64 for ubuntu server for A2?
15:44:15 <Daviey> skaet: that is th plan
15:44:19 <ScottK> o/
15:44:29 <skaet> thanks Daviey.
15:44:32 <skaet> go ScottK
15:44:45 <ScottK> Is the intent only to release amd64 for server or this that just for now?
15:45:00 <ScottK> ..
15:45:11 <ScottK> Daviey: ^^
15:45:20 <Daviey> ScottK: the current plan is to only realease and amd64 large iso for final.
15:45:34 <Daviey> ScottK: mini.iso, and netboot still fully supported.
15:45:55 <ScottK> Sigh.  OK.  Thanks.
15:45:58 <Daviey> ScottK: A1 didn't have any negative feedback, but still building and reviewing feedback as it goes.
15:46:08 <Daviey> ScottK: Why sigh?
15:46:17 <ScottK> I have 32bit only hardware.
15:46:33 <infinity> ScottK: installing from mini/net are usually more pleasant experiences anyway. :P
15:46:38 <ScottK> Heh.
15:46:42 <Daviey> ScottK: which hardware?
15:46:46 <infinity> ScottK: Unless you're the only man in the world whose network is slower than a CD or USB key.
15:46:56 <ScottK> infinity: Probably not.
15:47:21 <Daviey> ScottK: part of the reason to 'just do it' was to flush out server hardware which is 32bit only.
15:47:26 <ScottK> Daviey: A combination of older Intel Atom processors and Pentium IIIs.
15:47:36 <Daviey> ScottK: Alpha 1 yielded no feedback.
15:47:51 <ScottK> Right, because I don't reinstall servers for Alpha 1.
15:48:00 <Daviey> ScottK: And you use the large iso image to install them?
15:48:06 <stgraber> 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:12 <ScottK> I did last time I did it.
15:48:19 <ScottK> I tend to just upgrade them.
15:48:47 <xnox> 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:52 <Daviey> ScottK: do you think many users will be impacted for new installs?
15:49:20 <ScottK> Daviey: Not installs of new hardware, but if they have a problem and have to reinstall something on existing hardware.
15:49:39 <seb128> should we move that discussion to lists maybe?
15:49:47 <seb128> it probably interest people out of this meeting ;-)
15:49:51 <Daviey> Okay, i'll take the action of being verbal on devel
15:49:55 <Daviey> ..
15:49:58 <skaet> astraljava,  will your team be participating in A2?   which images if so?
15:50:03 <ScottK> Fine with me.
15:50:55 <arosales> o/
15:51:11 * skaet not sure if astraljava is still around....
15:51:18 <skaet> go ahead arosales
15:51:30 <arosales> 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:31 <arosales> ..
15:51:49 <skaet> 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:12 <astraljava> Sorry, I'm here. Yep, Xubuntu will participate in Alpha-2. Images: alternates and desktops, both archs.
15:52:15 <astraljava> ..
15:52:22 <skaet> thanks astraljava.  :)
15:52:36 <infinity> arosales: There's actually more agument for cloud images having a 32-bit option than server ISOs.
15:53:13 <infinity> (Cause lots of people do 32-on-64 for workloads with small memory footprints)
15:53:13 <seb128> 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:24 <stgraber> o/
15:53:27 <seb128> skaet, afaik nothing planned for unity stack out for SRUs
15:53:32 <popey> correct
15:53:34 <seb128> out of SRUs
15:53:39 <skaet> thanks seb128, popey
15:53:46 <skaet> ..
15:53:56 * ogra_ jumps
15:53:59 <skaet> have a nice evening seb128,  those were the main ones.
15:53:59 <arosales> infinity: main concern there is foot print size?
15:54:04 <skaet> for you.
15:54:14 <seb128> skaet, thanks, I will read scrollback and list if there is any question
15:54:15 <seb128> ..
15:54:35 <skaet> go stgraber
15:55:05 <infinity> arosales: Not the install footprint, but the in-memory footprint, yes.
15:55:40 <stgraber> 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:07 <stgraber> 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:31 <skaet> thanks for the heads up.
15:56:36 <stgraber> 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:39 <stgraber> ..
15:57:10 <skaet> 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:21 <arosales> 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:25 <stgraber> o/
15:57:27 <tumbleweed> o/
15:57:36 <infinity> o/
15:57:56 <skaet> skaet o/  ;)
15:58:00 <infinity> skaet: THat was an "I'm here", not a "I think we should extend the meeting".
15:58:22 <ogra_> extending the meeting needs both arms raised, right ?
15:58:28 <ogra_> :)
15:58:31 <popey> skaet, i need to scoot and do some compiz SRU work.. can I please be excused? :)
15:58:37 <skaet> ScottK and Riddell are around, but I'm not seeing signs of Laney.
15:58:52 <infinity> Laney's around.
15:58:54 <skaet> thanks popey for joining us.
15:59:02 <ScottK> o/
15:59:05 <Laney> greetings
15:59:11 <popey> skaet, sil2100 can answer if you have any questions for me
15:59:16 <Laney> I thought this meeting was from 1700-1800 BST
15:59:22 <ogra_> UTC
15:59:28 <Laney> so just checked in to see that it had been going for an hour
15:59:30 <Laney> the horror!
15:59:36 <skaet> :)
15:59:41 <Riddell> o/
16:00:06 <stgraber> slangasek, NCommander were talking in other channels not too long ago, they might be around too
16:00:11 <skaet> I think we're close enough to quorum,   any one feel strongly scheduling something different,  or continue on now.
16:00:19 * NCommander is around
16:01:04 <Laney> this is fine
16:01:09 <skaet> 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:45 <Laney> 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:47 <ogra_> doesnt that depend on the infrastructure the QA team will build up in early august ?
16:02:20 <ogra_> (else we cant do any automated arm testing afaik)
16:02:25 <infinity> 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:54 <infinity> ogra_: Automation is important, but probably not related to this.
16:03:00 <ogra_> k
16:03:07 <ogra_> i thought it was a requirement
16:03:10 <infinity> ogra_: It's the culture of "we only manually test right before milestones, then panic" that needs fixing.
16:03:21 <skaet> +1 on that.   :)
16:03:52 <skaet> anyone else have thoughts to add to infinity's?
16:04:16 <ScottK> 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:34 <infinity> 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:42 <Riddell> 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:53 <infinity> As in, once our QA processes are more sane, milestones will almost "obviously" become a complete waste of time.
16:04:57 <ogra_> so set a milestone for your people
16:04:59 <stgraber> 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:10 <ogra_> stgraber, ++
16:05:11 <stgraber> we can then look at the results of these changes and discuss the next step for the next cycle
16:05:12 <ogra_> and +
16:05:13 <Laney> ScottK: Possibly true. I don't know what effect the -proposed redirection would have.
16:05:29 * ogra_ also thinks its way to ruched
16:05:34 <ogra_> *rushed
16:05:38 <ScottK> 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:55 <infinity> ScottK: That's a process issue.
16:06:04 <tumbleweed> 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:23 <infinity> 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:24 <ScottK> tumbleweed: That's the right order to look at it.
16:06:42 <ogra_> and thats why i assumed the automated testing was a req.
16:07:00 <infinity> ogra_: We don't have automated testing for ARM at milestone times either. :P
16:07:16 <ogra_> infinity, nope, i assumed daily testing though
16:07:27 <infinity> 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:37 <ogra_> yes
16:07:47 <ogra_> and i agree with that, you still need the drive by testers
16:08:07 <ogra_> and as i wrote in my mail we mostly get them *after* the milestone due to the announcement
16:08:16 <infinity> 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:24 <xnox> 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:35 <infinity> If I find a scary bug 2 weeks before an Alpha, or two days after, it's just as critical.
16:08:36 <ubottu> Error: Launchpad bug 2 could not be found
16:08:44 <ogra_> heh
16:08:46 <ScottK> xnox: Not really.
16:08:47 <balloons> xnox, +1. I like the idea of having focused efforts of testing around things that make sense
16:08:52 <tumbleweed> 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:14 <ogra_> tumbleweed, well, or through other events ... thats why i asked if there was anythin planned
16:09:17 <astraljava> balloons: That's what we (Xubuntu) was hoping for, as well.
16:09:22 <astraljava> were
16:09:28 <infinity> tumbleweed: Our images 3 days after milestones are often better than the milestone. :P
16:09:46 <tumbleweed> :)
16:09:47 <infinity> 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:49 <Daviey> I pretty firmly disagree with dropping of freeze and/or milestones.. but seems i am a minority
16:09:51 <infinity> (Yes, this actually happens)
16:09:58 <ScottK> Daviey: I agree with you.
16:10:12 <NCommander> asdo I, but I've reclused myself from this topic and its dusciussion
16:10:14 <balloons> 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:31 <Laney> One would hope that quality is increasing as we go on.
16:10:39 * 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:47 <infinity> Anyhow, I think there's a horse and carriage issue here, where people immediately jump to the conclusion without the interim.
16:10:49 <Daviey> xnox: +1!
16:11:00 <Laney> Anyway.
16:11:02 <ScottK> 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:02 <xnox> by dropping milestones, it's effectively switching to a rolling release schedule
16:11:23 <ScottK> NCommander: reclused/recused.
16:11:24 <infinity> 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:31 * NCommander coughs
16:11:32 <ogra_> balloons, but you were lucky that no installer changes landed that broke installability
16:11:40 <Laney> I wanted us to have this discussion so that we, as the release team, can present "our opinion".
16:11:47 <skaet> 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:19 <infinity> ogra_: If we're breaking installability, we need to fix that too. :P
16:12:30 <ogra_> infinity, sure, not saying we shouldnt
16:12:32 <Daviey> 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:46 <ogra_> but having a daily bootable and installable is a matter of luck currently
16:12:48 <ScottK> 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:10 <xnox> 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:17 <infinity> 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:35 <ogra_> infinity, right
16:13:36 <Laney> 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:55 <Daviey> infinity: I understood the 'rolling miletsone' would be a two week cadence for manual testing
16:14:05 <ScottK> Laney: Community QA and their process only affects Ubuntu images.
16:14:16 <infinity> Daviey: That seems to be a first cut attempt from balloons' team.
16:14:23 <infinity> Daviey: That's hardly set in stone.
16:14:30 <ScottK> They've made that very clear, so it's not sufficient by definition.
16:14:30 <Daviey> Laney: do you want to gauge release team votes to indicate excitement for this change ?
16:14:41 <Laney> ScottK: Yeah. I think that's unfortunate and we need to work out how to fix that too.
16:14:58 <infinity> 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:49 <xnox> infinity: and there will be daily testing and no daily development?!
16:15:50 <infinity> 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:03 <ogra_> xnox, for 1h
16:16:08 <ogra_> of one team member
16:16:11 <ScottK> infinity: That's true.
16:16:18 <infinity> 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:29 <ogra_> *grin*
16:16:30 <Daviey> 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:46 <xnox> ogra_: RAID install takes longer than 1h
16:16:59 <ogra_> xnox, arm live image installs too
16:17:07 <infinity> xnox: Not one hour that you have to stare at it, surely.
16:17:15 <Daviey> I'm reasonably happy with the daily RAID testing to not make that a weekly by-hand test
16:17:15 * infinity image tests in the background while, like, working.
16:17:32 <ogra_> xnox, we should never enable raid on arm live images i conclude :)
16:17:43 <infinity> Turns out computers are pretty good at doing stuff even when I'm not staring at them.
16:17:50 <ScottK> infinity: Me too, but not on anything that requires sustained concentration.
16:17:53 <xnox> ogra_: oh but we are =) anyway this is off topic
16:18:25 <Daviey> So.. there seems to be no measure of peoples view on this?
16:18:26 <infinity> 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:33 <ScottK> Heh.
16:19:09 <ScottK> 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:16 <skaet> 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:34 <ScottK> I don't think anyone is opposed to encouraging additional testing between milestones so there's less surpise.
16:19:35 <skaet> is that a reasonable summary ^ ?
16:20:00 <infinity> I'd add "culture" to your infrastructure comment, but sure.
16:20:06 <ScottK> infinity: Yes.
16:20:14 <skaet> infinity,  agreed.  :)
16:20:14 <infinity> 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:20 <ScottK> skaet: For Alpha 2 I think that's right.
16:21:05 <Laney> I would like to make it clear that any changes to the release process must bring the flavours along.
16:21:13 * Daviey has to go now, but i'd like it noted that i am not keen on these changes.
16:21:22 <skaet> Laney,  agreed.
16:21:30 <ScottK> skaet: I think one of the key progenitors of change is how we message Alpha/Beta releases.  As infinity has said, a current daily is often better than last weeks Alpha and we need a way to communicate that.
16:21:33 <infinity> I kinda want to see a day where "daily" and "milestone" are pretty much the same thing.  But that's a loooong way out, and requires a lot of process, infrastructure, and cultural shift, and we may never get there.
16:22:04 <skaet> I think we all agree its a good long term goal.    Challenge is to get there in sensible steps.
16:22:14 <ogra_> ++
16:22:22 <infinity> But I think it's still a worthy goal to work toward, not for the end itself, but for the things it buys us along the way (consistency, better QA, etc)
16:23:02 <stgraber> more than alpha-2, I think we shouldn't be changing the way we freeze the archive or when we freeze it or when we release our milestones for this cycle. We all agreed on a release schedule at the beginning of the cycle, I don't think changing it afterwards is a good idea.
16:23:23 <stgraber> However that doesn't prevent us in any way in encouraging daily testing or implementing the -proposed changes we agreed on.
16:23:32 <infinity> Right.
16:23:40 <skaet> yup.
16:23:44 <Daviey> skaet: no, we don't all agree it's a good long term goal :)
16:23:45 <infinity> And as those things happen, I hope we'll see that milestones become easier and easier.
16:23:59 <infinity> To the point where first the freeze, then the milestone itself, seem like wasted effort.
16:24:07 <skaet> Daviey,  I suspect this won't be the last conversation on this.
16:24:09 <skaet> :)
16:24:13 <Daviey> :))
16:24:23 <Laney> I'm not really clear on what the freeze is when we get -proposed going.
16:24:31 <Laney> Is it that we turn off migration?
16:24:38 <stgraber> Laney: yes
16:24:46 <infinity> Daviey: I'll talk with you later about this, cause I want more on your position.  Go have a life in your timezone. :P
16:25:07 <stgraber> Laney: we move from auto-migration to migration for non-seeded and the release team can manually copy anything that's seeded and required for the milestone
16:25:14 <Laney> But if migration is doing its job properly then maybe it becomes unnecessary to do that.
16:25:27 <skaet> #ACTION:  skaet to start off a blueprint for -r release for people to record ideas and thoughts on logical steps for making progress to the long term goal.
16:25:27 * meetingology :  skaet to start off a blueprint for -r release for people to record ideas and thoughts on logical steps for making progress to the long term goal.
16:25:31 <stgraber> Laney: auto-migration will prevent skew, it won't prevent broken software
16:25:50 <Laney> Quality™ does that :P
16:25:57 <xnox> I would want the smoketests to prevent publishing daily-images, to save wasted time of manual testers.
16:26:05 <xnox> automated.
16:26:29 <skaet> xnox,  that's a good criteria to consider.
16:26:36 <Laney> You know, like the comprehensive regression testing suites we'll run on proposed.
16:26:52 <stgraber> Laney: in a perfect world, nobody introduces bugs and we'd have 100% code coverage of everything just in case they did, but we're pretty far from that ;)
16:27:00 <xnox> Laney: UTAH automatic install & reboot tests on bare metal is better.
16:27:17 <ogra_> ++
16:27:38 <Laney> There will of course be multiple layers of testing, I'm just saying that maybe there comes a point where freezing isn't worth it
16:27:44 <xnox> Laney: the -proposed tests will do nothing if the resulting cdimage is borked and non-usable to boot.
16:28:03 <ogra_> or to install
16:28:03 <Laney> I didn't say that it was the only testing.
16:28:07 <Laney> sigh.
16:28:29 * ogra_ thinks we have two different topics going on here
16:28:49 <skaet> ok,  I think we're winding down.   #ubuntu-release for more discussion on this.   We'll free up the meeting channel now,  and set up some infrastructure to keep the constructive dialog and planning going.
16:29:01 <stgraber> Laney: the only way we'll see if -proposed is good enough not to require freezing is by having -proposed implemented while still having our freezes. If we find that the release team copies everything, then the freeze isn't needed.
16:29:27 <Laney> that is almost exactly what I was trying to suggest
16:29:47 <skaet> Thanks to everyone for their patience on the extended meeting today.
16:30:04 <arosales> thanks for chairing skaet
16:30:19 <skaet> Thanks Daviey, arosales, ogra_, popey, brendand, Riddell, infinity, ScottK, stgraber, balloons,  brendand, highvoltage, astraljava,  xnox, seb128, Laney, tumbleweed for your participation in the meeting today. :)
16:30:23 <skaet> #endmeeting