15:00:39 <skaet> #startmeeting 15:00:39 <meetingology> Meeting started Fri Aug 24 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:56 <skaet> Agenda (and minute location): 15:00:56 <skaet> https://wiki.ubuntu.com/ReleaseTeam/Meeting/2012-08-24 15:00:56 <skaet> . 15:00:56 <skaet> Upcoming dates: 15:00:56 <skaet> 12.10 15:00:56 <skaet> 2012/08/30: Quantal Beta 1 Freeze and User Interface Freeze 15:00:58 <skaet> 2012/09/06: 12.10 Beta 1 15:01:00 <skaet> . 15:01:02 <skaet> Work Items: 15:01:04 <skaet> 2012/08/24 - 3011 (was 3011 (last week): We are behind the trendline for some of the projects. 15:01:07 <skaet> We�ve now gone into Feature Freeze, so getting us back on track would be appreciated. If something is clearly not going to make it this cycle, please mark it POSTPONED. 15:01:10 <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:13 <skaet> . 15:01:15 <skaet> Bugs: 15:01:19 <skaet> Quantal: http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html 15:01:21 <skaet> . 15:01:23 <skaet> Weekly Status Received: 15:01:25 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001786.html - Kubuntu - Riddell 15:01:27 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001788.html - PS - popey 15:01:29 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001790.html - 12.04.1 testing - jibel 15:01:31 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001792.html - Kernel - ogasawara 15:01:33 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001794.html - Security - jdstrand 15:01:35 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001795.html - Ubuntu One - joshuahoover 15:01:38 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001798.html - Lubuntu - gilir 15:01:40 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001803.html - Edubuntu - stgraber 15:01:42 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001804.html - Linaro - fabo 15:01:44 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001805.html - Desktop - seb128 15:01:48 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001806.html - hwcert - brendand 15:01:51 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001807.html - QA - gema 15:01:52 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001808.html - foundations - ogra 15:01:54 <skaet> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001813.html - server - arosales 15:01:56 <skaet> ?? - community testing - balloons 15:01:58 <skaet> ?? - Xubuntu - astraljava 15:02:00 <skaet> ?? - Ubuntu Studio - scott-work 15:02:02 <skaet> . 15:02:04 <skaet> Thank you to everyone participating in getting 12.04.1 released! I was contrasting the number of bug fixes, reviews, image builds, testing we did with 10.04.1 informally and we�ve definitely up�d the game. Well done! 15:02:16 <skaet> #topic Questions and Comments 15:03:10 <skaet> So now that 12.04.1 is out the door, focus solidifies on 12.10 :) Yesterday was Feature Freeze, and based on the burn down charts - its pretty clear there are some things coming in late. 15:03:10 <skaet> Open question for today is Feature Freeze exceptions - what�s needed? 15:03:52 <skaet> any one have "o/" before I start into some questions? 15:05:22 * seb128 lists desktop ffe exceptions in his email (sorry for sending it only today, I didn't have all the infos yesterday and we were still crazy busy landing work) 15:05:26 <skaet> popey - for the compiz features landing, which bug is being used to track the FFe? we�ll be going into UIF next week - will UIFe be needed as well, or will all the bits land by then. 15:05:51 <skaet> seb128, yup understood 15:06:09 <popey> We haven't created a bug yet for FFe, guidance welcome in that regard. Do we have just one master FFe bug or individual bugs per feature? 15:06:32 <skaet> popey, probably one per component, with what's planned to land would work. 15:07:09 <skaet> popey, I'll get together with you afterwards then and we can sort it a bit. 15:07:10 <popey> ok, we can do that, do we need to subscribe a team/person? 15:07:15 <popey> ok, great, that will help 15:07:16 <popey> ... 15:07:41 <skaet> will all the pieces land by next Thursday (User Interface Freeze)? 15:07:54 <popey> almost certainly not 15:08:49 <skaet> hmm... so most of it won't make Beta 1 then. yeah, we'll need to be figuring out a plan, since this will ripple into multiple other teams (docs, translations etc.) 15:09:05 <smartboyhw> Er, balloons's smuumary: https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001815.html 15:09:14 <seb128> popey, which ones do you see missing uif? 15:09:38 <popey> probably webapps 15:12:04 <ogra_> o/ 15:12:05 * skaet thanks smartboyhw for posting balloons summary 15:12:12 <smartboyhw> NP 15:13:29 <skaet> .. (I think) 15:13:37 <popey> oops yes, .. 15:13:43 <skaet> :) 15:13:47 <skaet> go ogra_ 15:14:08 <ogra_> seb128, your report indicates you guys are looking into compiz GLES .... just wanting to make sure :) 15:14:13 <ogra_> .. 15:14:22 <seb128> ogra_, it's landed in compiz trunk 15:14:26 <ogra_> i know 15:14:32 <ogra_> but not in the archive :) 15:14:39 <seb128> we separated from compiz-gsettings to not have too much transitions going on at the same time 15:14:45 <seb128> and that needs to land with the new unity 15:14:50 <seb128> which is late on other things 15:15:03 <seb128> having gsettings out of the way will make the next update easier hopefully 15:15:26 <ogra_> right, i just want to know if i need to switch the panda images to openbox for final :) 15:15:27 <seb128> so gles and new unity are scheduled for next week (earlier than late if possible) 15:15:28 <seb128> .. 15:15:34 <ogra_> awesome, thanks ! 15:15:37 <seb128> yw 15:15:40 <ogra_> .. 15:15:42 <seb128> (depends if you get drivers I gues) 15:15:44 <seb128> .. 15:15:44 <popey> +1 seb128 it'll be first thing we do next week 15:15:45 <popey> .. 15:15:47 <ogra_> we have drivers 15:15:55 <seb128> ok, so we should be good soon 15:15:59 <ogra_> just paperwork missing 15:16:26 <ogra_> libdri2 was uploaded to NEW before the meetingg, once thats in the archive i'll upload the PVR package and we are golden 15:16:27 <ogra_> .. 15:17:26 <rsalveti> \o/ 15:17:41 <rsalveti> .. 15:17:47 <skaet> thanks. :) I think this just answered the question I was going to ask from fabo's report too. 15:17:49 <skaet> .. 15:18:20 <ogra_> :) 15:18:21 <skaet> seb128, did you get together with TheMuso on the accessibility tests? would be good to have that resolved before Beta1 15:19:05 <seb128> skaet, I didn't manage to catch him on IRC but I sent an email out this morning, will be resolved by next meeting for sure (if he doesn't reply I will just go ahead and make the test list) 15:19:17 <skaet> thanks seb128 15:19:30 <seb128> np, sorry it's taking so long :-( 15:19:37 <skaet> .. 15:20:18 <skaet> any one else have "o/" today? 15:20:28 <gema> o/ 15:20:31 <skaet> go gema 15:20:48 <gema> I'd like to talk about the grief we've had in QA due to all the last minute respins 15:21:05 <gema> and how we are expected to react, rather than being able to plan 15:21:27 <gema> in my opinion 15:21:43 <gema> Quality is not about shipping without errors, it is about shipping predictable software, documenting the problems found gives us a better chance at the release than introducing new problems last minute trying to solve those 15:21:50 <stgraber> would you have preferred we ship with an image that doesn't fit on a media? 15:21:57 <gema> stgraber: yes 15:22:36 <gema> stgraber: because now we are shipping something that fits on a media but may have extra errors that we don't know about 15:22:50 <gema> stgraber: so I prefer to ship known quality than unknown quality 15:23:00 <brendand> stgraber, when you say 'fits on a media', you mean not even USB stick? 15:23:16 <slangasek> the 12.04 images are specified to fit on a CD 15:23:16 <stgraber> brendand: we're talking 12.04, 12.04 needs to fit on a standard 700MB media 15:23:30 <slangasek> if it's oversized, it's not fit to purpose 15:23:41 <stgraber> brendand: we had a last minute detected oversized image that required a respin yesterday 15:24:07 <stgraber> the real problem is that the image was build on the 17th and it took until the publishing, a few hours before release to notice it was oversized 15:24:20 <stgraber> so that means nobody tested using the target media (blank CD, standard size) 15:25:06 <brendand> gema - that does need to be part of QA, no? 15:25:22 <gema> brendand: ideally, that image should fail in the build system if it is oversized 15:25:31 <gema> brendand: but yeah, we should have a test case for that 15:25:34 <slangasek> no, that's not ideal 15:25:35 <Laney> I don't think that's ideal 15:25:41 <gema> why not? 15:25:57 <slangasek> there are many cases where we know we can't get the image down to size yet during development, but we still need to have an image available for testing 15:26:19 <gema> slangasek: I remember seeing warnings of that on the website where you publish the imates 15:26:22 <gema> images 15:26:23 <brendand> gema, i think it's the difference between releasing it and just having an image to test 15:26:44 <brendand> gema, you can *test* an oversized image, but you can't release it 15:26:55 <slangasek> we *should* catch oversized issues much sooner than when we're going to publish; the problem is that the only place the information is published is on cdimage.ubuntu.com, where no one was looking 15:26:59 <gema> I don't see why you cannot release it, but that is besides the point 15:27:05 <slangasek> (because the ISO tracker hides that implementation detail) 15:27:14 <gema> we can add a mandatory test case to the tracker so that we don't forget to check in the future 15:27:17 <gema> and issue solved 15:27:21 <gema> that's not my problem 15:27:23 <slangasek> gema: because we specified that we were releasing CD images for 12.04, and this was not a CD image 15:28:07 <slangasek> stgraber and I have discussed what needs to happen so that oversized images are flagged much earlier to the release team as well, so this particular problem doesn't recur 15:28:28 <gema> cool, slangasek, as I said, it is not one particular problem that bothers me 15:28:31 <stgraber> FWIW we didn't have any fallback image for amd64 and amd64+mac, so as we had the requirement of releasing a CD image, I had the option to fix + respin or not release the 64bit image 15:28:39 <slangasek> gema: right; I understand that 15:28:43 <gema> the respin on wed was equally problematic in my view 15:28:46 <gema> due to a corner case 15:29:12 <stgraber> I still think the decision to respin was right, I ran a full diff of the livefs and cd content, so I have the exact list of files that changed as well as their content, all the tests were ran against the 64bit livefs and they all passed 15:29:47 <gema> stgraber: I still think it is wrong, but it is ok to disagree on this 15:29:59 <gema> what I am more worried about is how lightly we take respinning 15:30:10 <gema> and how little consideration we give to QA in the process 15:30:14 <slangasek> I don't think it's being taken lightly at all 15:30:15 <stgraber> so we essentially released a fully tested image, if that's not the case, then something is wrong with the testcase list on the tracker, because they certainly were telling me everything was tested 15:30:27 <skaet> respinning is not taken lightly at all. 15:30:37 <Daviey> Yeah, i am quite suprised there is complaint at this. 15:30:37 <slangasek> it's a pain for everyone involved, both in QA and in the release team 15:30:46 <Daviey> repining is documented for the reasoning why 15:30:49 <slangasek> it's *more* of a pain for the QA team, certainly 15:31:06 <Daviey> There was at least one issue, which would have been nice to include.. but wasn't respan for, that i know of. 15:31:33 <stgraber> in this case, the pain was really on me more than QA to be honnest, I am the one who had to spend 3 hours fixing the image, do the respin, do the diffs and did most of the amd64 testing (while jibel was doing amd64+mac smoke test) 15:31:46 <slangasek> but even if QA was automatic and instantaneous, a respin still throws off the release team's schedule... we're having to react to such changes just as much as QA does 15:32:12 <gema> slangasek: I am not saying you guys are not suffering from it 15:32:22 <gema> I am saying it can be made less painful for everyone 15:32:27 <stgraber> we had to delay the release accordingly, making quite a lot of people on the release team work overtime (not to mention the folks in London who had to stay up until past midnight) 15:32:28 <gema> if we all work together towards that 15:32:42 <Daviey> well, the phrasing of "little consideration" does imply that care wasn't taken. 15:32:58 <gema> Daviey: I said taken lightly, I think 15:33:14 <Daviey> < gema> and how little consideration we give to QA in the process 15:33:16 <gema> but english is not my first language, so didn't try to offend anyone 15:33:18 <Daviey> but anyway. 15:33:21 <gema> ahh, ok, yes 15:33:40 <gema> that's how I felt and I have had conversations with other fellow testers which felt the same way 15:33:55 <gema> all I am asking for is to consider revising the process and introducing changes 15:34:04 <slangasek> how would you revise the process? 15:34:08 <skaet> gema, constructive suggestions on ways we can improve are useful, but we do need to meet produce images that are fitting the purpose on a time basis, so have to take that into account 15:34:19 <gema> skaet: agreed 15:34:27 <slangasek> I don't expect we're going to change the process to declare that we never respin 15:34:31 <gema> slangasek: I don't know, I need to think about that 15:34:34 <slangasek> ok :) 15:35:07 <gema> slangasek: change is good if it is to fix things, they just need to be fixed in time for us to be able to test 15:35:34 <gema> and stgraber having only your opinion on how good/bad the images are doesn't fill me with as much confidence as if most of the QA team had had a chance to test the images 15:35:40 <gema> nothing personal, just a matter of coverage 15:35:47 <skaet> and getting the manual testing to be efficient has to be part of it though. 15:35:50 <gema> and confidence that more eyes went through the changes 15:35:57 <slangasek> gema: sure, I understand; and part of the calculation the release team needs to make is whether a bug is so important to fix (i.e., is "stop ship") that we would want to let the image be delayed rather than release it as-is 15:36:03 <stgraber> gema: well, I surely would have liked to go back in time and respin the image on the 17th, unfortunately that's not an option... so we spotted that at the last minute and as we're doing time based releases, had to fix, retest and release in just a few hours 15:36:19 <stgraber> I'm not saying that's a good thing, but that's how things are and we have to live with it 15:36:28 <skaet> gema, the change was that we dropped a language pack, we figured out the impact and took the risk, with a fall back. 15:36:30 <gema> stgraber: we could have delayed the release until today 15:36:42 <gema> stgraber: there were other options 15:36:42 <skaet> gema, we're a time based release. 15:36:55 <Daviey> gema: surely the whole point of posting results to the iso tracker, is to allow the release team to consider if a respin is needed? 15:37:07 <Daviey> Polling each member of the QA team is odd. 15:37:17 <gema> Daviey: I am not asking for that 15:37:18 <slangasek> so does that mean the respun image didn't go through the ISO testing process? 15:37:26 <Daviey> Personally, i think the product managers require more input than the QA team. 15:37:47 <stgraber> as far as I'm concerned, if the product lead signs-off and I have all testcases covered on the tracker, an image is good to ship 15:37:54 <Daviey> +1 15:37:58 <stgraber> if that's not the case, then the process needs fixing to reflect that 15:38:13 <gema> stgraber: agreed 15:38:16 <skaet> slangasek, jibel and stgraber went through the test cases so it did go through ISO testing process 15:38:17 <gema> it needs to change 15:38:35 <Daviey> gema: What aspect ? 15:38:38 <jocarter> what should change, specifically, gema? 15:38:54 <gema> the approach is wrong 15:39:11 <gema> having a set of results on the tracker from the same people that are making the changes is just not enough confidence 15:39:15 <gema> imo 15:39:27 <Daviey> I always considered it such that the release team makes the call on what is releasable, with input from the QA team for testing and approval from the product managers. 15:39:40 <gema> we need to plan for the time it takes to have more HW covered in our testing 15:39:42 <Daviey> gema: That isn't the apprach 15:39:45 <Daviey> approach 15:39:53 <stgraber> Daviey: yep, that's how it should be. The release team is the one making the release decision, not QA. 15:39:55 <xnox> gema: do you mean: as in three pairs of eyeballs minimum? one to change, one to test, one to sign off? 15:40:14 <gema> xnox: along those lines, but we need to review and agree on something more solid 15:40:15 <Daviey> gema: The fact that in prior history, the QA team wasn't able to give us the coverage, meant that we had to do it within the product teams for it to get done. 15:40:17 <gema> imo 15:40:21 <Daviey> Thankfully, this is improving 15:40:33 <skaet> +1 15:40:52 <gema> exactly Daviey 15:40:59 <balloons> I think gema is concerned these exceptions are more often the norm in releasing. We all agree last minute testing and fixing is not the ideal way to go (working overtime, doing everything last minute and on a time crunch, etc) 15:41:01 <gema> yet our opinion doesn't really count 15:41:33 <stgraber> FWIW, I wouldn't have trusted an image with a single tester, but in this case, I did the change, infinity reviewed it, IS reviewed and landed it and the image was tested by me, jibel and balloons 15:41:45 <stgraber> so that's way enough eyeballs as far as I'm concerned 15:41:45 <balloons> I will say I am impressed with the release team as a whole in order to mount efforts to stay on the timetable.. you deserve credit for that 15:42:28 <jocarter> balloons: and besides that even... they keep level-headed and calm and professional even when they're tired and overworked. I have lots of respect for the release team. 15:42:58 <gema> I would rather them not overworking to be able to achieve the releasing 15:43:04 <gema> :) 15:43:14 <gema> but +1 balloons and jocarter 15:43:54 <skaet> Will you be circulating an email to ubuntu-release with your ideas on ways we can improve? 15:43:57 <skaet> gema, ^ 15:44:00 <Daviey> It's really not clear to me what you are suggesting changing. Nobody wants last minute dashes, and thankfully.. they are on the decline. 15:44:07 <balloons> so I think everyone's goal here is the same.. we don't want last minute changes being the norm for releasing.. To gema's points, we need to investigate (as always) what can be done to avoid the last minute changes.. However, gema it sounds like you might be able to come up with a better way of handling them.. 15:44:10 <skaet> where we is QA, release, development. 15:44:16 <balloons> at least something that helps your confidence level? 15:44:30 <gema> skaet: I cannot nor want to decide this unilaterally, I think we need to talk 15:44:52 <gema> skaet: I will put a list of ideas together if you like, but nothing will change until we all agree that there is a problem 15:44:54 <skaet> gema, I was asking for ideas on an email thread so we can continue this discussion. 15:45:07 <gema> if you guys don't see it then I am not presenting a good case and I need to rethink that 15:45:10 <skaet> the timing is right now, for good discussion, and then follow up at UDS. 15:45:25 <gema> skaet: ok 15:45:37 <Daviey> gema: All that has been said so far as far as i can see, is "the current process doesn't take QA's view enough into account".. but a specific idea of what you'd like to see improved, would really help 15:46:02 <gema> Daviey: ok, I will put that in an email and send it to you guys for further discussion 15:46:10 <Daviey> super, thanks. 15:46:18 <gema> will try to give specific examples as well as generic ideas 15:46:35 <balloons> gema, consider walking through hypothetical examples and talk about how you feel it's handled now, vs how you wish it to be handled 15:46:38 <balloons> +1 15:46:53 <gema> balloons: you arae going to help me build that email, I hope :) 15:47:03 <gema> with your experiences as well 15:47:21 <Daviey> that leads to a them an us, lets have an open discussion :) 15:47:25 <balloons> gema, I would be happy to.. It's important to frame how you feel it's being handled as well.. we sometimes assume or understand things incorrectly :-) 15:47:47 <gema> balloons: I am not afraid of being wrong, I do QA for a living 15:48:12 <balloons> gema, kick off your thoughts, we'll all pitch back reponses 15:48:19 <gema> ack 15:48:24 <gema> I am done , skaet 15:48:25 <gema> .. 15:48:49 <skaet> Thanks gema. 15:48:57 <arosales> o/ 15:49:03 <skaet> go arosales 15:49:21 <arosales> server will most likely have a FFE for ARM support in MAAS and oprofile (universe) 15:49:22 <arosales> .. 15:49:59 <skaet> Thanks arosales, please include the bug number of it in your next week's status if its not resolved by then. ;) 15:50:07 <skaet> on that note - when do you see it landing? 15:50:40 <Daviey> looking at the development RSN. 15:50:46 * xnox 0/ 15:50:49 <skaet> RSN? 15:50:55 <Daviey> real soon now 15:50:59 <skaet> lol 15:51:02 <arosales> skaet: no firm ETA yet, but hopefully mid sept 15:51:30 <skaet> ok, after beta 1, so definitely need to be communicating it and planning. gotcha. 15:51:35 <arosales> actively working on both items 15:51:41 * skaet nods 15:51:46 <arosales> .. 15:51:52 <skaet> .. 15:51:58 <balloons> o/ 15:52:00 <skaet> go xnox 15:52:30 <xnox> ubiquity - lvm & crypto in manual partitionaire, might slip UIF and hence might need FFe for that functionality. 15:53:29 <xnox> to be bugfiles & discussed on how to best land it to minimise disruptions, since landing that might brake the installer. (e.g. after crypto work landed there were 3 bugs preventing sertain type of installs due to fallout). 15:53:36 <xnox> s/bugfiles/bugfiled/ 15:54:09 <skaet> thanks xnox. ogra_ will you please make sure the bugs are included in your status next week? 15:54:10 <xnox> (after crypto work, the images were fixed 3 or 5 days later, can't remember) 15:54:21 <xnox> .. 15:54:29 <ogra_> skaet, will do 15:54:47 <skaet> slangasek, will we be turning off alternates for beta 1? 15:55:10 <skaet> thanks ogra_, xnox for raising it here. 15:56:12 <xnox> .. 15:56:17 <slangasek> skaet: I need to kick off a thread on ubuntu-devel about it to gather feedback about the missing RAID support; I'll do that today or Monday, I think we can probably converge quickly on a decision in time for the beta freeze 15:56:22 <Laney> o/ 15:56:31 <skaet> thanks slangasek. 15:56:35 <skaet> .. 15:56:39 <skaet> go balloons 15:57:37 <balloons> I just wanted to chat briefly about what I mentioned in my mail.. How we communicate with the community is important, if we want to continue building a good working relationship 15:57:59 <balloons> Recently some of the changes have caused a bit of grief for those testing.. 15:59:27 <balloons> I can get into specifics, but I would rather focus on what we can do to ensure we are communicating more effectively with our testing community. To some extent, that's a worry for me :-) Hence me bringing it up. There's technical and non-technical ideas -- should be communicate more within the desktop, or should we require folks to follow a certain mailing list, etc, etc 15:59:53 <skaet> seb128, popey - any ideas how we can help balloons? 16:00:32 * skaet is thinking of the 2D and 3D scenario evolving... ;) 16:00:33 <balloons> Mostly I'd like to make sure that big changes that will have an effect on what's going on in QA are discussed here.. That generally happens, but not always.. 16:00:36 <seb128> not really, I don't have the specifics? 16:00:44 <seb128> is that about unity-2d dropping and the impact on vms? 16:00:51 <balloons> Well, for instance I'll pick on the nvidia / xorg change 16:01:22 <seb128> what would you have liked to see better done there? 16:01:35 <balloons> That change obviously impacted alot of people.. A few day s after popey and the unity team wanted some triaging on multi-monitor bugs, and of course the unity/compiz changes 16:01:47 <popey> is it that the people affected didn't know the issue was coming down the line, or they did know and are still adversely affected anyway? What's the most irritation there? 16:01:49 <seb128> it was announced on -devel but admittedly late and in a non really verbose way 16:02:19 <balloons> yes, I don't think the fact the change went in (and would break things for people) is as much of a concern as the fact it was unknown 16:02:25 <ogra_> seb128, even in the planning it was awfully hidden ... 16:02:30 <seb128> imho we should use -devel to announce such things 16:02:34 <balloons> so it was a, you update, and boom your stuff is broken 16:02:41 <seb128> I'm still unhappy about how -release handled the xorg,nvidia stuff 16:02:42 <ogra_> seb128, there is one spec where dropping of unity-2d is mentioned in a half sentence 16:03:18 <ogra_> beyond things like the mentioning of it on ubuntugeel and omgubuntu, you couldnt really find any official info about the move 16:03:18 <seb128> well, different story: 16:03:39 <seb128> - nvidia,xorg was a known issue, poorly handled from -release imho and poorly communicated to -devel our community 16:03:45 <popey> I don't think -devel is the best way to communicate critical things like this to people. I'd be surprised if many quantal users are on that list. 16:03:51 <ogra_> i think that step is a big enough move qith enough impact that it would have deserved a full spec 16:03:59 <seb128> - unity-2d was publicly announced in plenty of spaces and specs 16:04:01 <balloons> yes I agree.. -devel isn't the place to announce 16:04:08 <balloons> well.. not the only place :-) 16:04:23 <ogra_> written by DX (with explanations what are the plans, tests etc) ... and implemented by desktop 16:04:28 <seb128> popey, what easy communication channel do we have? 16:04:47 <ogra_> .. 16:04:54 <popey> OMG!Ubuntu! :) 16:04:57 <seb128> popey, easy, like for those of use who don't spend hours every day on every social website on the internet :p 16:05:05 <popey> heh 16:05:21 <balloons> to some extent that falls on me.. and I'm happy to help in that regard 16:05:29 <seb128> popey, I've no clue how to get something published on omgubuntu and I don't consider it an official media channel 16:05:37 <popey> if you went to omg / webupd8 / muktware you'd hit a _huge_ number of people in one go 16:05:37 <seb128> well 16:05:50 <ogra_> seb128, delegate bloging to one of you team members then ;) 16:05:52 <seb128> I'm happy to improve how we communicate 16:05:52 <balloons> Getting an official channel for this stuff.. right now, ubuntu-qa mailing list is a good start, but there are folks who aren't on the list 16:06:04 <popey> i completely understand that perspective seb128 16:06:06 <ogra_> if you think planet is a more official mediam 16:06:09 <ogra_> *medium 16:06:09 <seb128> ogra_, nobody in my team is into blogging 16:06:17 <popey> but what we're doing is something "newsworthy" so we should publish it as "news" 16:06:33 <balloons> imho, somehow sending it out to users when they update would be really cool.. but, in general if we could manage to alert at least those who are actively testing and helping it would go a long way 16:06:42 <seb128> we should maybe set up a "news feed" then 16:06:52 <Laney> there's already a news team 16:07:02 <seb128> where feed is whatever you guys who do communication find an efficient way to deal with news 16:07:02 <Laney> could we CC such announcements there and have it get out that way? 16:07:03 <Daviey> Generally, all engineering teams need to get better at blogging. 16:07:16 <seb128> Daviey, we are back at what ogra was saying though 16:07:23 <seb128> blog will reach 1% users 16:07:46 <seb128> I don't read blogs, I've no time for that, and I'm sure a good part of our users have no interest in blogs or planet ubuntu 16:07:49 <Daviey> Yes, but OMG et al will no doubt use it as a reference for continuation stories 16:07:58 <ogra_> seb128, well, before that i said it should have been planned better (by DX) ... if there is a spec it is way better noticed by the community 16:08:12 <balloons> I guess I would at least like to know about things like this in advance.. and in general the other leads in this meeting should also know 16:08:14 <seb128> that seems like a "rely on some other people to do something you don't know if they are going to do" 16:08:20 <skaet> some sort of push of info to all folks who are registered as wanting to help test (subscribed to related test cases?) could be an option to reach those affected as well? 16:08:21 <ogra_> and people might watch its implementation status (and are prepared of whats coming) 16:08:28 * Daviey notes that El Reg almost wrote a story about something i added to the wiki alone. 16:08:46 <seb128> ogra_, sorry, what you talking about? xorg,nvidia or unity2d? 16:08:55 <seb128> ogra_, unity2d dropping had full specs 16:09:17 <seb128> ogra_, and was discussed at UDS in public sessions 16:09:26 <Daviey> Perhaps I am biased, but i'm more annoyed that X/libdrm broke *server* install media. :) 16:09:35 <ogra_> seb128, spec url ? 16:09:57 <seb128> ogra_, in fact I even announced it during the closing plenary 16:09:59 <ogra_> seb128, sorry, but all i can find is a single sentence from a BOF discussion note in one of the desktop team specs 16:09:59 <seb128> from my notes 16:10:03 <balloons> seb128, I believe unity2d was a known thing.. people knew it would happen.. they may have been a bit surprised when it did, but again, they were prepared on the idea 16:10:15 <seb128> "llvmpipe and opengles support in Unity 3D -> dropping 2d if we can (a11y, llvmpipe performanc, gsettings support to compiz)" 16:10:30 <seb128> balloons, seems ogra was not 16:10:43 <seb128> ogra_, let's take that out of meeting, that's a bit off topic 16:10:56 <ogra_> seb128, i knew it .... when i asked about it the answer was "we dont know yet" 16:10:56 <skaet> hmm.. we're a bit over now, but this topic probably should be taken to the maillist as well now. 16:11:03 <seb128> going back to the better communication way, I don't have a strong opinion 16:11:07 <ogra_> seb128, and there was no spec i could look up the plans 16:11:15 <ogra_> (or anyone from the community could) 16:11:18 <balloons> ok, so coming back around on this. I would like to see us internally communicating better.. 16:11:27 <balloons> I will help distribute that to others.. 16:11:33 <seb128> what about letting popey, balloons and whoever is interested define a channel others should use for announces? 16:11:39 <balloons> longer term finding better channels is the goal 16:11:53 <Daviey> balloons: external communication would surely be better than internal ? :) 16:11:53 <ogra_> i'm not complaining about not knowing it, i'm complaining about the whole thing not having been documented and planned in advance so that people can look up whats jjhappening 16:11:56 <skaet> balloons are you getting what you need from the weekly section of == what's about to land that will affect other teams == ? 16:12:02 <seb128> popey, balloons: want to work on defining a standard workflow that teams should use to get news out? 16:12:05 <popey> we have a communications team 16:12:13 <balloons> for instance, slangasek's annouce about dropping alt images.. people know about it. let's try and communicate that clearly now 16:12:28 <balloons> Since I heard about it here, I can communicate it out and look for his email 16:12:53 <ogra_> seb128, there were plenty people in the community asking about unity-2d and the status (and if they could help testing llvmpipe) since months 16:13:06 <ogra_> there was no place to point them to 16:13:32 <seb128> ogra_, let's take that particular issue out of the meeting, it's specific 16:14:03 <skaet> balloons, can you start a thread off on this, so we can continue to add our ideas? 16:14:10 <balloons> skaet, sure 16:14:15 <skaet> Thanks 16:14:26 <skaet> Laney, still have a question before I end the meeting? 16:14:33 <Laney> well, it's kind of a note 16:14:38 <skaet> :) 16:14:53 <Laney> the indicator gtk2 dropping has broken xubuntu, lubuntu, ubuntustudio 16:15:16 <Laney> I didn't see any note of that in their release reports 16:15:21 <Laney> just wanted to check that it was known 16:15:29 <balloons> Laney, bug? 16:15:30 <xnox> Laney: is it pending splitting source package in two & uploading old gtk2-only package? 16:15:45 <skaet> gilir, astraljava, scott-work ^^ 16:16:10 <gilir> Laney, it's known, we are trying to find a solution to upload a gtk2 source 16:16:12 <xnox> balloons: there was thread on -release or -devel where the feedback was gathered about dropping gtk2-indicators 16:16:14 <Laney> xnox: I suppose that and a maintainer 16:16:30 <Laney> balloons: I don't have a bug number, just noted that the images were no longer building because of this 16:16:40 <skaet> thanks Laney 16:16:53 <Laney> so, probably a concern for beta 1 for these product 16:16:54 <Laney> s 16:17:18 <Laney> .. 16:17:24 <skaet> appreciate you bringing it up here. Thanks. 16:17:44 <skaet> ok, we're way over, so time to end meeting.... 16:17:54 <Daviey> Thanks. 16:17:54 <skaet> please take follow up to the ubuntu-release email list. 16:18:10 <skaet> Thanks balloons, gema, arosales, seb128, popey, slangasek, stgraber, Daviey, smartboyhw, ogra_, rsalveti, brendand, Laney, jocarter, xnox, for the good discussions today. 16:18:14 <skaet> #endmeeting