=== asac_ is now known as asac [16:01] pedro_, bdmurray, ogasawara: ping [16:01] howdy [16:01] heno_: pong! [16:01] * ogasawara waves [16:01] o/ [16:01] hi there [16:01] #startmeeting [16:01] Meeting started at 16:01. The chair is heno_. [16:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:02] welcome all! [16:02] we have an agenda here https://wiki.ubuntu.com/QATeam [16:04] I have nothing to add to the agenda [16:04] [TOPIC] Spec status [16:04] New Topic: Spec status [16:04] is everyone who has specs comfortable with getting them written up and with the review process? [16:05] I'm new to the review process, but I'll ask questions if and when I have any [16:05] is there a wiki describing the review process somewhere? [16:06] With regards to an informational spec is it necessary to write up the spec? With the QA schedule it seems a bit redundant. [16:06] the review team is listed here https://edge.launchpad.net/~ubuntu-reviewers [16:06] my DesktopAutomatedTests is basically written, I'm just going to review it myself before submitting it for review; SelfTestingDesktop is still to be written, but since it's a corollary of the other one, it should be pretty quick to do [16:06] you should ask one of them to review when you feel it's complete [16:07] I don't see a wiki page [16:07] heno_: I assume we should submit for review by the end of the week? [16:07] this should have been covered by the UDS howto I guess [16:08] ogasawara: yes, that would be good, to allow for some ping-pong [16:09] stgraber: did you make it to the meeting? you have several specs needing review also [16:09] stgraber: (let me know if we should have a post-UDS conversation about this) [16:10] ok, that seems clear; moving on [16:11] [ACTION] everyone should complete the spec formulations and submit them for review by the end of this week [16:11] ACTION received: everyone should complete the spec formulations and submit them for review by the end of this week [16:11] [TOPIC] Feedback on Hardy QA schedule [16:11] New Topic: Feedback on Hardy QA schedule [16:12] Brian asked for some feedback on the QA schedule on the list [16:12] the schedule looked fine to me [16:12] me too [16:13] yep good for me too [16:13] bdmurray: will you pass it on the the release team next? [16:13] good for me too, even if it doesn't have a date for when I'm allowed to report fourteen thousand bugs automatically [16:13] heno_: sure - they don't have a mailing list right? [16:14] I don't think they do, no [16:14] pedro_: looking at it again I seem to have missed forwarding bugs upstream that would be until about week 8 right? [16:14] liw: I guess that would be when we can trust it to DTRT [16:15] heno, sure, I was trying to be funny anyway [16:15] bdmurray: you mean Gutsy bugs? I assume we forward bugs continuously in the dev release [16:16] i don't think so [16:16] heno_: We discussed forwarding being more helpful until syncs stop [16:17] s/more helpful/useful/ [16:17] after which we need to patch our version of the package [16:18] bdmurray: are they considered less useful closer to release because upstream are less likely to fix or because of ubuntu-specific changes [16:18] gnome is a special case that gets synced quite late I guess [16:19] liw: sure. are there automated-test milestones that should go on a regular schedule though I wonder? [16:19] it might be difficult to tell in our first cycle of doing it [16:20] heno_: because after import freeze the packages become more divirgent so while upstream may have fixed the bug they may have also done a lot of other things that we can't sync after import freeze [16:20] heno, I don't think so, for the first cycle [16:20] ok [16:21] bdmurray: ok. I guess at that point developers will upstream individual issues they feel they need help with [16:21] [AGREED] Everyone agreed that it was a nice schedule :) [16:21] AGREED received: Everyone agreed that it was a nice schedule :) [16:22] [TOPIC] Gutsy bug triage, looking for SRU candidates [16:22] New Topic: Gutsy bug triage, looking for SRU candidates [16:24] I've been doing a fair bit of SRU verification for candidates already identified [16:25] there is only about a week and a half left of this phase. is it coordinated with the release team WRT for how long we will roll out fixes? [16:26] I'm here [16:26] roughly how many bugs have we identified so far that should get gutsy SRUs? [16:26] The schedule is an indication of our primary focus after this week and a half we will shift to looking more at Hardy [16:26] * heno_ waves to stgraber [16:27] ogasawara: do you have the gutsy verification needed query? [16:27] are there any gutsy bugs that stick out as esp. high-profile? [16:28] bdmurray: I'll check, just a sec [16:28] how many are new and how many are ones we didn't mange to fix before release? [16:28] I think I have verified the updates for most of the really high-profile ones [16:28] yes, I have 4 specs to work on, I've already talked a bit with _nand about the Tokamak one, I'll try to work on that tomorrow morning (note the "try" as I have a lot of other things to do :)) [16:29] btw, davmor2 asked me to paste that during the meeting : [16:29] 14:16 < davmor2> 1/ would it be better to bug test before the end of the freeze? That way when the freeze is on everything should be stable? [16:29] 14:16 < davmor2> 2/ with the schedule there is iso-testing latter on but not at the beginning is that how it is meant to be? [16:29] stgraber: indeed. let me know if you need help with those [16:30] bdmurray: I don't [16:30] stgraber: The schedule just indicates where our primary focus lies, iso-testing can happen as early as Alpha 1 [16:30] bdmurray: but it shouldn't be hard to do [16:30] * bdmurray waits for it [16:31] 2> by 'ISO testing' here we mean intensive testing with redundant coverage involving the dev team and others [16:31] shouldn't be something like https://bugs.launchpad.net/ubuntu/gutsy/+bugs?field.tag=verification-needed ? [16:32] whereas earlier we do more spot/sanity checks on ISOs [16:32] pedro_: sure enough [16:32] there's also http://people.ubuntu.com/~ubuntu-archive/pending-sru.html [16:32] eww, the link I've got in launchpad is long [16:33] I'm working on 17595 atm [16:34] nice page [16:34] one thing about the lp query is it doesn't show the repository [16:36] on davmor2's pt. 1, I'm not sure which freeze he is referring to. Things do change after the freeze too though and simple errors can get introduced that are not caught by regular use [16:37] such as the late change cause the Kubuntu installer to fail [16:37] which I think was typo-level coding error [16:38] ok, let's move the the next topic, which is related but needs some discussion [16:39] [TOPIC] Managing Gutsy and Dapper SRU nominees [16:39] New Topic: Managing Gutsy and Dapper SRU nominees [16:39] please look at https://edge.launchpad.net/ubuntu/gutsy/+nominations [16:40] and https://edge.launchpad.net/ubuntu/dapper/+nominations [16:40] The nominations are where anybody decides to nominate a bug for a release right? [16:41] right [16:41] How or why should they be managed? [16:42] we need to look at that list regularly to identify good candidates and make sure those reports get triaged [16:42] so that they can be moved forward to qualify for the SRU process [16:43] some will be not important enough and the nominations should be rejected [16:43] do you folks have the LP powers to accept/decline those? [16:44] I think only ubuntu-drivers does [16:44] which explains why I can [16:45] I can too - for spec stuff at UDS I was added to that team [16:45] I think the core triage team at least should have those powers [16:45] I can't :-( [16:46] One thing about this process that bothers me is anyone can nominate [16:46] ok, I'll ask for pedro_ and ogasawara to be granted the appropriate LP powers [16:46] thanks [16:46] looking at bug 109882 it is one person with the issue and they nominated the bug [16:46] great [16:46] Launchpad bug 109882 in fedora "Headphone automute not working" [Unknown,Fix released] https://launchpad.net/bugs/109882 [16:46] bdmurray: true, that makes it noisy. but the lists are not extremely long [16:46] bdmurray: heh, was just looking at that too [16:47] ogasawara: does l-b-m have the right version of alsa? [16:47] bdmurray: I think the version of alsa they want might already be in lbm [16:47] jinx you owe me a beer [16:47] bdmurray: checking on it right now [16:47] the advantage is that it can help bring up important issues [16:48] provided we look at the list regularly and it doesn't get abused [16:49] bdmurray: many of those were nominated before the gutsy release, when it made more sense, as that wouldn't be an SRU [16:50] we should do a one-time run-through after each release to remove those that clearly don't qualify [16:50] bdmurray: can bughelper help us identify those? [16:50] heno_: I haven't looked at the nomination property of a bug before but will look into it [16:51] thanks [16:51] it doesn't look like the point at which it was nominated gets logged automatically [16:53] bdmurray: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy-lbm.git;a=commit;h=d33c164bb93d09f21fd331a726052b66e40c26ab [16:54] all: please look out for nominated bugs when looking at gutsy bugs these days and ask me or brian to reject obvious non-SRU candidates [16:54] I'll do a more explicit run-through of that list next week [16:55] ook [16:55] ogasawara: do you want to follow up on the bug and I'll rjeect the nominations? [16:55] bdmurray: sure [16:56] well, that's wacky [16:56] then nominations show up on a per package basis [16:56] let's revisit the status of this list next week. there are currently 358 bugs on it [16:56] so declining it for gutsy did it for both packages [16:57] which wasn't what I expected [16:58] heno_: we are only concerned about nominations for packages in main right? [16:59] hm, good question. it would be good to clean the list generally [16:59] where is the MOTU policy on updates? [17:00] is it mainly backports? [17:00] I think they incorporated it into the main SRU policy [17:00] * Hobbsee looks in [17:01] yep, I see it now [17:01] heno_: pretty much the same as main, although a little less beaurocracy. new features --> backports, bugfixes --> SRU [17:02] * bdmurray waves to Hobbsee [17:03] Hobbsee: ok. who from MOTU could we get to go through that list regularly? the MOTU council perhaps? [17:03] also, you shouldn't have to be a driver to accept/reject such nominations [17:04] I'm not sure they belong on that list in the first place [17:05] from the user's POV it makes sense to nominate packages equally though [17:06] I'll raise that question on the MOTU list and with various ubuntu drivers [17:07] [ACTION] mdz to evaluate list of Gutsy nominated bugs and raise questions on the MOTU and devel lists [17:07] ACTION received: mdz to evaluate list of Gutsy nominated bugs and raise questions on the MOTU and devel lists [17:08] heh - 154 nominated bugs are "New" [17:08] indeed, which is why the QA team has a role to play in an initial screening of the list [17:08] oh, thisthing doesnt flash when done backwards. [17:08] bdmurray: hiya! [17:09] heno_: erm, you only have to be in -release to accept or deny the nominations [17:09] heno_: sec, let me see the list. i wasnt following :) [17:09] some of them will need improving (triaging) soonish, while others are less important and should be pushed to hardy [17:10] Hobbsee: was the universe report helpful at all? [17:10] bdmurray: it wasnt what i was looking for, but it looks somewhat useful. [17:11] Hobbsee: okay well let me know if you need anything else [17:11] heno_: ubuntu-universe-sponsors does it usually. [17:11] bdmurray: will do. but not at 4am :) [17:12] Hobbsee: ok, thanks [17:12] heno_: but there may be another team starting up to do it. unsure. will find out in the next week or so [17:12] [TOPIC] QA team weekly meeting times [17:12] New Topic: QA team weekly meeting times [17:12] always a controversial one :) [17:13] bdmurray: what time is 16.00 in OR? [17:13] just do away with the meetings. problem solved :P [17:13] we've tried that before :p [17:13] I think these meetings are useful, although they take a bit longer than I'd like [17:14] ut that was before we had a team really ;) [17:14] it's 09:14 in Oregon (US west coast) right now [17:14] right 1600 was 0800 [17:14] ok, so earlier would not be so good [17:15] yes, that would be bad [17:15] wouldn't be good for me neither (would be at school) [17:15] liw: I agree, we should try to limit them to 1hr. [17:15] I'm not throughly happy about 1600 UTC, but I can live with this (especially, as noted, if we can make them at most 1 hour :) [17:16] we have alternated times on various meeting in the past, but that's not a great solution either [17:16] yeah, a constant time would be best, makes it easiest to plan ahead [17:16] for me, at least [17:16] indeed [17:16] liw: and 18.00, say, would be worse I take it [17:17] I'm an evening person, so I don't mind either way [17:17] I'm UTC+2 (UTC+3 during daylight savings time), so 18 UTC would be 20 (or 21), which would mean I won't get anything else done that evening [17:17] ^ Would be perfect for me :) but indeed I doubt liw would be happy with it [17:18] especially since Wednesdays are typical days for meeting people socially [17:19] so basically I'm in favor of keeping 1600 UTC [17:19] ok, with one for and one against, we'll leave it as it is for now [17:19] sorry stgraber :( [17:20] stgraber, indeed, sorry [17:20] ok, well for me as you saw the best case is 17h30 at home, usually it'll be 18h30 and then will miss the meeting [17:20] as I was 1minute away from missing my bus :) [17:20] perhaps we should consider a community meeting sometimes on the weekend [17:21] let's see how well attended the QA-related sessions are this weekend [17:21] (arranged by the LoCo teams I think) [17:22] [AGREED] Leave the meeting time at 16.00 UTC [17:22] AGREED received: Leave the meeting time at 16.00 UTC [17:22] can be revisited later [17:22] ok, let's stop there [17:22] thanks everyone for attending! [17:23] #endmeeting [17:23] Meeting finished at 17:23. [17:23] thanks you! [17:23] heno, thanks for e-mailing the agenda, it was useful, at least to me [17:24] feel free to email me agenda items during the week. Is sending it out the same morning early enough or should I try for the day before? [17:24] team-OR ^ [17:24] I'd prefer the day before [17:25] (I'm not sure I could promise that though :) ) [17:25] ok, I'll try :) [17:25] eh, not a big deal ;) === j_ack_ is now known as j_ack [19:42] Is the meeting for developers only, or can someone about to deploy to 500 computer listen in? [19:43] Goosemoose, its all public :) [19:44] ok, thanks [19:52] @now Madrid [19:52] Current time in Europe/Madrid: November 14 2007, 20:52:53 - Next meeting: Desktop Team Development in 17 hours 7 minutes [20:01] === edubuntu meeting === [20:02] * RichEd waves to see who is here ? [20:02] I'm [20:02] * ogra waves [20:03] Just the three of us then ? [20:04] * ajmitch is lurking as usual [20:04] no sbalneav ... [20:04] or LaserJock [20:05] mrm ... wanted to explain a bit about the new edubuntu add-on structure ... which we all know about already from UDS [20:05] sorry [20:05] hey hey :) [20:06] so RichEd wants to start of tech today :) [20:06] LaserJock: glad you are here :) [20:07] we need your opinions and valued wisdom (and your healthy dose of skepticism) [20:07] haha [20:07] okay so we all know that edubuntu will be a CD2 installed on top of Ubuntu CD 1 [20:08] so the benefit to us, is that all the "generic operating system" issues will belong to the Distro team ... [20:08] freeing us up to look at the education layer on top [20:08] what I wanted to ask was ... what are the drawbacks ? [20:08] what must we be careful of on the way into this process [20:08] testing will also be a lot easier as we'll probably simply ask people testing Ubuntu to then install Edubuntu and quickly test it [20:09] yeah [20:10] ogra: did we work out all the CD issues ... server and desktop ? [20:10] not yet, we'll do that along the way [20:10] there are to many bits involved ... [20:10] for now i need to finish the spec, it has to be complete by next thursday [20:10] drawbacks, IMO, are going to be a bit of confusion to users, what do we do with the LiveCD?, and perhaps shipit unless that is resolved [20:11] live will persist as iso [20:11] as a Demo CD? [20:11] well, as is [20:11] is it going to be installable? [20:11] LaserJock that's the sort of thing I mean ... ogra needs to be able to gp into the planning with a set of requirements from our user base [20:11] hmm, I really wish we could rip ubiquity out of the LiveCD [20:11] s/go/gp/ [20:11] LaserJock, why ? [20:12] ogra: because I think it causes confusion and is another support case [20:12] well, I think that we should clearly explain why Edubuntu is now an Add-on to Ubuntu and why it was done that way and make clear that this way we'll be able to focus more on Edubuntu than previously (as for some people it would certainly look like we are working less on Edubuntu as we do less stuff which isn't the case) [20:12] argh, me and my long sentences ... [20:13] well, indeed we need to phrase that properly to not scare off people [20:14] stgraber: yes ... we need to be able to get a message out about the benefits of the changes ... there is another change as well to edubuntu distro development structure which we will chat about later. [20:14] on a sidenote all ltsp functionallity will move to the ubuntu alternate CD [20:14] as it is in edubuntu today [20:14] so we can chat about those togeter later in the meeting [20:15] I just want Edubuntu to be simple [20:15] so if we need to be able to describe the "user" requirements: [20:15] and make sure they can get the CDs easily and install easily. [20:15] so for a desktop user, they'd get Ubuntu CD1 + Edubuntu Add-on CD [20:16] for Edubuntu server, what CDs/images would they need oliver ? [20:17] ubuntu alternate and edubuntu addon or ubuntu server and edubuntu addon, depending on the usecase [20:17] and are both of those ubuntu alternate and ubuntu server available from shipit ? [20:17] no [20:17] only ubuntu server is [20:17] alternate was dropped several releases ago [20:18] so you're referring to the need for the LTSP packages ? [20:18] right [20:18] server is on Shipit? I don't remember seeing it [20:18] I just checked and wasn't able to find it on shipit [20:19] even if I have one of those CD just next to me :) [20:19] alternate will have the required desktop packages needed for the ltsp desktop and the former edubuntu ltsp installer integration [20:19] well, if it isnt, i'm sure it will be for hardy [20:19] server would be the ground for edubuntu-content-server [20:20] we should check out the plan there ... [20:20] or alter also a proxy with webfilter [20:20] *later [20:20] I'll make a note to ask in the "office" [20:20] we'll need a *lot* of documentation [20:21] I'm a little worried about Edubuntu just dissolving into so many projects [20:21] its only one project [20:21] only one real CD [20:21] ogra: could you install ubuntu server + download & install LTSP + edubuntu addon to get there ? [20:21] well, but parts are going on various CDs [20:22] RichEd, rather ubuntu-desktop [20:22] which requires communication with the various teams [20:22] which is something we haven't been very good at in the past [20:22] LaserJock, edu irrelevant packages like ltsp go where they belong [20:22] yes, but right now Edubuntu == LTSP [20:22] beyond that all edu related packages go on the edubuntu CD [20:22] LaserJock all the support burdens and development burdens move to ubuntu distro [20:23] RichEd: right, that's the problem [20:23] that is a huge benefit in terms of where ogra can put his effort [20:23] we're going to be depending a lot on other teams [20:23] which means we need to have very good communication [20:23] and it's more difficult to get a view of what's going on [20:23] LaserJock, well, would you think apache would belong under edubuntu maintenance if we shipped it on todays edubuntu-server CD ? [20:24] on some level yes [20:24] okay ... so let me introduce the "other news" then ... and you'll see the fuller picture ... [20:24] if we ship it we have to make sure it's tested, works, and works the way we think it does [20:24] we need to talk all of this through to make sure you core guys are happy and comfortable [20:24] if the server team does something to LTSP that hurts our "typical users" then it's our problem [20:25] regardless of who is actually maintaining it [20:25] LaserJock hang on ... this is how it will work ... [20:25] well, i think that will still largely be me in the future :) [20:25] but lets listen to RichEd [20:26] our overall requirements for education related developement solutions go from education -> distro [20:26] and the entire team tackles the education requirement. [20:27] so where the need is recognised as being education ... it is allocated to ogra [20:27] if it is generic ubuntu related ... then it is allocated through the distro team to the right ubuntu team [20:27] so ogra is the Edubuntu Technical Lead [20:28] he will define what he needs as a spec for the requirements of the target audience ... and it is tackled as a team job [20:28] inside the distro team ... [20:28] yep ... [20:29] * ajmitch will be glad to see LTSP being used in more than just education [20:29] ok, well that's all good an well from a Canonical/Manager perspective [20:29] but when we're trying to build a developer community [20:29] right ... so that is why I started off by saying I want to hear about the drawbacks of what lies ahead ... so we can get them as criteria that need to be satisfied [20:29] and somebody asks how they can help, and we point them to the server team, or desktop team, or perhaps UME even, etc. [20:29] depends [20:30] if what they want to do is edubuntu related we need to find the right tasks for them there [20:30] if someone asks how they can help through our community, we should use them for education specific work [20:31] if they are server specialists they will be better off in the server team but still with input and requirements we bring up to them [20:31] LaserJock: so look at something like our education mass maintenance requirement [20:31] that request has come in from education before any requests from ubuntu server [20:32] well look, I never said we shouldn't do this [20:32] so ogra defines the need, and we spec it ... and the distro team needs to find a way to resolve it ... [20:32] I'm just saying we really really need to figure out the community consequences [20:32] and work on the communication that we'll need to make it work [20:33] and ogra makes sure it fits what we need, but the work is alloctated to far more people resource than we have access to [20:33] so we have access in effect to the entire developer community, and not just our developer community [20:34] we need a core Edubuntu developer community to work on the applications / features that touch our education community [20:35] LaserJock: expand a bit if you can ? [20:35] well, there's two "issues" I see with this [20:35] 1) Edubuntu is currently primarily an LTSP distro [20:36] LaserJock, ubuntu will become that regardless of edubuntu [20:36] right [20:36] darn it, I'm not arguing against that [20:36] the long term goal for me for hardy is to have sbalneav in core-dev [20:36] I'm trying to get us to think about what we need to do to deal with that [20:36] so you will have an upstream maintained ltsp in ubuntu ... [20:37] 2) it makes contribution to Edubuntu as a whole more difficult [20:37] edubuntu might loose some of its shinyness here, but it will gain a huge value for spare developer time [20:37] 1) Edubuntu is currently primarily an LTSP distro <- that's a statement ... what's the issue ? [20:38] RichEd: it will no longer be so [20:38] RichEd, it wont be anymore [20:38] how not ? [20:38] it wont be the LTSP in one go distro anymore ... [20:38] that will be ubuntu alternate [20:39] which I think everybody agrees is the proper thing to do [20:39] edubuntu will only add the edu bits t it [20:39] LTSP is much more than just classrooms [20:39] *to [20:39] or as you commented above ogra: ubuntuCD1 + download & install LTSP + edubuntu AddOn [20:39] right [20:39] RichEd, "one go" [20:39] but we can't expect that to go over well with users necessarily [20:39] put in the CD, answer 5 questions, go for a coffee, boot your clients [20:40] we have to make sure users know what's going on [20:40] document it very well [20:40] right [20:40] the different combination options will be confusing [20:40] we need a "what for what" doc [20:41] ogra: could the LTSP download & install be scripted and activiated from GUI ? [20:41] now, I think my second point is similar [20:41] RichEd, yes, we have a spec for that :) [20:41] how big is the download in question ? [20:41] if somebody running Edubuntu has a problem with LTSP what do we do? [20:41] and actually that app sits on my disk here, pretty much done [20:41] ~150M [20:41] if somebody wants to contribute a patch for LDAP stuff, where do we send them [20:42] LaserJock, we support him [20:42] we send him to the server team [20:42] (the latter one) [20:42] right [20:42] unless its any edubuntu specific issue with LDAP [20:42] so my point is that we become quite a bit more spread out [20:42] we're having to depend on other teams a lot more [20:42] say we ship edsadmin which nobody else uses for maintaining LDAP [20:42] so if the user could go to [system] [[admin]] [[[LTSP]]] and tick an icon and the rest is GUI driven ... that's easy enough for anyone ? [20:43] that can be quite daunting to users and potential contributors [20:43] then its an edubuntu issue [20:43] so we need to be prepared for that [20:43] ogra: could we get a "install edubuntu" menu option in anyplace after the ubuntu install ? [20:43] RichEd, yes, i have various GUI tools for LTSP stuff that will be in hardy, dont worry all such stuff will be there [20:44] RichEd, we could have a task on the alternate CD but indeed that requires a beefy connection [20:44] one that says: insert Edubuntu AddOn CD into your CD and then holds the users hand from there ? [20:44] surely not .... [20:45] thats something the installer team wont llow [20:45] (thats actually the way debian does it) [20:45] can you explain why in simple terms ? [20:45] no [20:45] else i would have done it in the sentence above already [20:45] i'll talk to them :) [20:46] we can have it on the addon cd [20:46] okay ... I'm thinking that once Ubuntu is installed and up and running (which is an easy process) we could have some sort of easy wizard to guide what you need to do next. [20:47] LaserJock, well, we will [20:47] but rich wants a hook in the ubuntu installer [20:48] I dont' think we need that though [20:48]