[00:00] <pleia2> ok, we're getting ready for an ubuntu community learning project meeting
[00:01] <bodhi_zazen> =)
[00:01] <bodhi_zazen> who is here for the meeting ?
[00:02]  * pleia2 
[00:02] <cprofitt> #startmeeting
[00:02] <MootBot> Meeting started at 18:02. The chair is cprofitt.
[00:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[00:02] <cprofitt> Hello all and welcome to the UCLP meeting
[00:02] <cprofitt> please just say here if you are present for the meeting
[00:02] <pleia2> thanks for chairing, cprofitt :)
[00:02] <pleia2> here
[00:02] <bodhi_zazen> here =)
[00:02] <swoody> o/
[00:03] <doctormo> here
[00:04] <cprofitt> I would like permission to open an agenda item not on the list.
[00:04] <pleia2> sure
[00:04] <cprofitt> [TOPIC] Civility
[00:04] <MootBot> New Topic:  Civility
[00:04] <cprofitt> I would like  to express a feeling that I think we all share...
[00:05] <cprofitt> that there is a need to be civil during meetings and discussions (formal and informal)
[00:06] <bodhi_zazen> +1 cprofitt
[00:06] <pleia2> being mindful of the CoC would help, and keeping in mind that we're all on the same team here
[00:06] <cprofitt> we each have our own passions involved in this project, but a person's passions should not control a project. We all need to do a better job of seeing the project from a holistic view and take the time to pause when considering the view points of others
[00:06] <bodhi_zazen> I think a lack of civil discourse is detrimental to this project
[00:07] <swoody> a big +1 on this...
[00:07] <cprofitt> I hope that we all reflect on potentially 'inflammatory' language and using it to make a point.
[00:08] <swoody> from my UCLP peon perspective, there is a lot of great talent and leadership in this project. I think being able to overcome your personal biases and opinions for the team this could be an amazing team :)
[00:08] <cprofitt> we really need to curb that... this is not a 'debate' club meeting, but a team trying to produce something to assist the community.
[00:08] <cprofitt> We all have one goal that is the same -- educate users and potential users
[00:08] <bodhi_zazen> I also think we need to re-focus our efforts and I think we should at least touch base on the fact that we are using Moodle to "repackage" or present material in ways condusive to learning, and not a documentation project
[00:09] <bodhi_zazen> documentation == wiki
[00:09] <cprofitt> can we wait on that bodhi_zazen
[00:09] <cprofitt> lets stick with the civility first.
[00:09] <cprofitt> please
[00:09] <bodhi_zazen> yep, but I am throwing it out as it seems related , it the root cause of problems
[00:10] <cprofitt> [VOTE] We all need to be more aware of the words we use in expressing our opinions and take time to understand the points of view different from our own
[00:10] <MootBot> Please vote on:  We all need to be more aware of the words we use in expressing our opinions and take time to understand the points of view different from our own.
[00:10] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[00:10] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[00:10] <cprofitt> +1
[00:10] <MootBot> +1 received from cprofitt. 1 for, 0 against. 0 have abstained. Count is now 1
[00:10] <pleia2> +1
[00:10] <MootBot> +1 received from pleia2. 2 for, 0 against. 0 have abstained. Count is now 2
[00:10] <swoody> +1
[00:10] <MootBot> +1 received from swoody. 3 for, 0 against. 0 have abstained. Count is now 3
[00:10] <bodhi_zazen> +1
[00:10] <MootBot> +1 received from bodhi_zazen. 4 for, 0 against. 0 have abstained. Count is now 4
[00:11] <cprofitt> any last votes?
[00:11] <cprofitt> last call for votes
[00:11] <cprofitt> [ENDVOTE]
[00:11] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[00:11] <cprofitt> [AGREED] The group agreed to make a conscious effort to be more civil
[00:11] <MootBot> AGREED received:  The group agreed to make a conscious effort to be more civil
[00:11] <cprofitt> thank you.
[00:11] <cprofitt> [TOPIC] Course Organization
[00:11] <MootBot> New Topic:  Course Organization
[00:12] <cprofitt> We discussed quite a bit of this on the list...
[00:12] <cprofitt> and I wish to reflect my understanding...
[00:12] <cprofitt> We are trying to make courses that will be A)  On-line via Moodle and/or IRC B) Course materials that can be used with in-person training
[00:13] <bodhi_zazen> o/
[00:13] <cprofitt> We will not force a course 'creator/author' to make content in all of those formats
[00:13] <cprofitt> the choice will be up to the course author
[00:13] <cprofitt> the team may try to convert material from one format to the other
[00:13] <cprofitt> ... is that accurate?
[00:14] <cprofitt> go ahead bodhi_zazen
[00:14] <bodhi_zazen> IMO our final product should be generic / versatile enough to be used in almost any content
[00:14] <pleia2> right, but the official course format is asciidoc, and if someone joins the team who just wants to write material (for any format) we will point them to doctormo's upcoming docs on how
[00:14] <bodhi_zazen> one should be able to use our "template" or outline in a classroom, IRC, independent study, should not really matter
[00:15] <cprofitt> pleia2, I missed several meetings... was the asciidoc format voted on?
[00:15] <pleia2> yeah, what bodhi_zazen said
[00:15] <pleia2> cprofitt: yes
[00:15] <Vantrax> im 90% afk sorry guys, very busy at work getting some things ready for deadline
[00:15] <pleia2> bios_element reviewed a number of formats and showed them all to us
[00:15] <pleia2> cprofitt: might want to check the mail archives for his full text email of his analysis
[00:16] <cprofitt> pleia2, have we posted that on our wiki page?
[00:16] <pleia2> ah, here we go: https://lists.ubuntu.com/archives/ubuntu-learning/2009-September/000050.html
[00:16] <cprofitt> we need to make sure that people have that information if they are considering assisting us.
[00:16] <cprofitt> thanks for the link to the comparison...
[00:17] <pleia2> cprofitt: doesn't look like it, we're waiting on finalization of doctormo's instructions before we have people diving in
[00:17] <pleia2> we need standards for this, doctormo and bioselement have been writing them :)
[00:17] <pleia2> (it's all in bzr)
[00:17] <cprofitt> I agree... but it might help us if it is mentioned as a standard... on our site even if we do not have a complete set of instructions
[00:17] <doctormo> Indeed
[00:18] <pleia2> cprofitt: we're trying
[00:18] <cprofitt> I think with that being officially adopted we should strive to have our first course actually be one that shows how to use asciidocs
[00:18] <cprofitt> inside our framework
[00:18] <doctormo> That was something BiosElement was working on.
[00:18] <pleia2> that's what doctormo and bioselement are writing...
[00:18] <cprofitt> pleia2, I would put a basic statement about it on the main page -- https://wiki.ubuntu.com/Learning
[00:18] <pleia2> ok
[00:18] <cprofitt> under the Course creation section
[00:19] <cprofitt> not a complete instruction set, but just a note that asciidocs will be used
[00:19] <cprofitt> We obviously will need the asciidoc course developed in Moodle and in-person format... would IRC be appropriate as well?
[00:20] <pleia2> yes, as I explained in my email the core material is in asciidoc, and then adapted for all three formats
[00:20] <cprofitt> ok.... cool...
[00:20] <cprofitt> sorry I did not recall that detail in your email.
[00:20] <cprofitt> doctormo, do you have an eta or target date for that course?
[00:20] <pleia2> cprofitt: https://lists.ubuntu.com/archives/ubuntu-learning/2009-October/000067.html
[00:21] <pleia2> sent it out 6 days ago
[00:21] <cprofitt> I remember the email, in general, but not the specific part about an asciidoc how-to course
[00:21] <pleia2> oh ok :)
[00:22] <cprofitt> I have been working on the Moodle examples... to assist us with that...
[00:22] <cprofitt> which I know you put in one of your emails.
[00:22] <doctormo> cprofitt: There is a few steps, one involves getting the bzr/lp checkout, one involves editing text files and the final one is commiting branches.
[00:23] <cprofitt> sounds good doctormo - I am just curious if you have a target date for the release of the course that will teach people how to produce courses for us
[00:23] <cprofitt> that will be an important step forward in having others contribute
[00:23] <doctormo> cprofitt: I'd targeted last month, but we just didn't reach it.
[00:23] <cprofitt> Trying for November then?
[00:24] <doctormo> Trying for January.
[00:24] <cprofitt> [ACTION] Doctormo is targeting January for finishing the course on how to contribute to UCLP
[00:24] <MootBot> ACTION received:  Doctormo is targeting January for finishing the course on how to contribute to UCLP
[00:24]  * cprofitt nods
[00:24] <bodhi_zazen> January :p (I understand, just couild not resist the emoticon)
[00:24] <cprofitt> OK...
[00:24] <doctormo> Hopefully it'll be done before then.
[00:24] <pleia2> in the meantime I've still been writing in odt
[00:24] <cprofitt> one other thing that I raised in my email.
[00:25] <cprofitt> I would like use to organize content in to sections
[00:25] <pleia2> I'll convert to asciidoc eventually, but we want to get rolling even if the official dev docs aren't done
[00:25] <cprofitt> so that we will not have material duplicated
[00:25]  * pleia2 nods
[00:26] <cprofitt> if there is a 'using ubuntu' strand that involved using nano and a 'maintaining' ubuntu strand that uses nano
[00:26] <doctormo> I've seen the sections that you want to create cprofitt, I'm not in agreement to the precise layout.
[00:26] <cprofitt> then content on nano would be in its own course
[00:26] <bodhi_zazen> and have people identify what section(s) they are working on
[00:26] <cprofitt> and in both strands
[00:26] <doctormo> But I think we've been over some of it
[00:26] <cprofitt> that is the general concept.
[00:26] <bodhi_zazen> If many people are working on sections, we need a way they can collaborate
[00:26] <pleia2> bodhi_zazen: that's already begun, it's being done on the wiki
[00:27] <doctormo> The organisational collaberation anyway
[00:27] <cprofitt> are you referring to this page pleia2 - https://wiki.ubuntu.com/Learning/UbuntuDesktopTopics
[00:27] <pleia2> cprofitt: yes, all 5 of the pages have owners
[00:27] <cprofitt> let me take some examples from there then
[00:27] <pleia2> then the sections are split off into "I'm working on this now" - so people can take ownership of them and let others know they're being worked on
[00:27] <pleia2> I am not sure we have to decide upon specifics of the courses at this meeting though
[00:28]  * Vantrax likes where this is heading
[00:28] <cprofitt> Synaptic Package Manager, Aptitude and Apt, What are repositories, and how do they work, Partitioning and Fstab, Linux file permissions, Sudo and Root, Linux file system hierarchy
[00:28] <cprofitt> those topics likely cross over to both the administering and the using areas
[00:28] <cprofitt> agree?
[00:29] <bodhi_zazen> I would put them in admin and not general use
[00:29] <cprofitt> I do not think we have to organize specifics, but I want to ensure we are understanding one another
[00:29] <cprofitt> but our 'use' has been labeled by the graphic as 'desktop'
[00:29] <bodhi_zazen> I think of using more of OOO, firefox, etc
[00:29] <cprofitt> and administering 'server'
[00:30] <pleia2> I think these topic labels are fluid, and I agree with bodhi_zazen
[00:30] <cprofitt> ok...
[00:30]  * cprofitt pauses
[00:30] <cprofitt> I am not sure I am communicating this well
[00:30] <cprofitt> I apologize
[00:30] <cprofitt> I think there is the potential for course overlap and wish to avoid that if possible
[00:31] <pleia2> yes
[00:31] <cprofitt> we have people in charge of the areas... but I think we need to have a process to look at those areas and not let them become silos
[00:31] <pleia2> the easiest way is putting topics on both pages, marking that they are responsible on both
[00:31] <cprofitt> that have over lapped content
[00:31] <pleia2> not the most elegant, but probably what we have to do
[00:31]  * cprofitt nods
[00:31] <doctormo> What was the thoughts on considering use to be the execution of goals that produce results outside of the computer's own self maintaientance.
[00:32] <cprofitt> pleia2, I think you and I are on the same page.
[00:32] <doctormo> People don't use vi or nano to edit their normal documents.
[00:32] <cprofitt> I am not concerned with the specifics, just the fact that we want to avoid duplication
[00:32] <bodhi_zazen> I do doctormo =)
[00:32] <Vantrax> I think there will be overlap, but there are different levels of detail in use in regard to applications
[00:32] <doctormo> bodhi_zazen: special case
[00:32] <cprofitt> Vantrax - I agree.
[00:33] <bodhi_zazen> I understand ;P
[00:33] <Vantrax> one should be an introduction to command line text editing (nano)
[00:33] <cprofitt> The key is to not produced 'base' levels inside several courses
[00:33] <Vantrax> one should be advanced command line text editing (vi)
[00:33] <swoody> +1 cprofitt
[00:33] <pleia2> cprofitt: +1
[00:33] <cprofitt> but to remove the 'base' level and make it its own course
[00:33] <bodhi_zazen> I for one suggest we do not separate out command line from graphical
[00:33] <doctormo> Overlap may not be too much of a problem, I don't think the project is big enough yet for it to be a problem and so long as organisation is being carried out on those few pages in the same form, it would be easy enough to check.
[00:33] <Vantrax> but there will be some overlap
[00:33] <bodhi_zazen> IMO command line tools should be included where appropriate
[00:33]  * cprofitt coughs
[00:34] <swoody> I think a general 'base' knowledge course, and then if needed, further info into a specific area if it's required for those needs
[00:34] <cprofitt> we are getting in to the specifics
[00:34] <bodhi_zazen> some content there will be more , others less =)
[00:34] <pleia2> doctormo: yeah, for now it's not too huge of an administrative challenge, but I think we want to make sure we're aware that it'll come up and to check for it :)
[00:34] <Vantrax> good point:P
[00:34] <cprofitt> I would prefer not to discuss the specifics... nor the probability of overlap...
[00:34] <Vantrax> Long as we are aware of the issue, and have a way to differentiate the different courses it will be fine
[00:34] <cprofitt> just to acknowledge that if it happens we will try to mitigate it
[00:34] <bodhi_zazen> +1 cprofitt
[00:34] <pleia2> if I start writing "now you aptitude install" in a Desktop course I'll be sure to cross-reference with Server course to make sure I'm not rewriting "basic aptitude" instructions
[00:34] <doctormo> cprofitt: The probability and the cost of administrating the overlap seem fairly pertinant.
[00:35] <bodhi_zazen> I also like the wiki syntax "using any editor"
[00:35] <bodhi_zazen> rather then specifying nano vs kate vs gvim
[00:35] <cprofitt> we will table the discussion to the mail list then doctormo
[00:35] <cprofitt> I motion we close this topic and move it to the mailing list
[00:35] <swoody> +1 bodhi_zazen , if how to use an editor has been covered by a previous 'base' topic
[00:35] <pleia2> cprofitt: +1
[00:35]  * cprofitt topic closed
[00:36] <doctormo> +0 I have no strong feelings about moving it anywhere, this place was as good as anywhere.
[00:36] <bodhi_zazen> swoody: that *should* be a linky to the wiki
[00:36] <cprofitt> does anyone else have any topics that were not put on the agenda?
[00:36] <pleia2> I'm going to blog about the project sometime this week
[00:36] <pleia2> mostly based on my email, try to remind people that we exist and all
[00:36] <doctormo> pleia2: Want me to blog at the same time?
[00:37] <pleia2> and I'm doing an Ubuntu Open Week presentation on it, so I'll share the draft of that with everyone soon in case you guys have things to add
[00:37]  * cprofitt nods
[00:37] <cprofitt> +1 pleia2
[00:37] <cprofitt> anyone else?
[00:37] <pleia2> doctormo: sure, maybe you discuss how the base documentation format (bzr, asciidoc) for the project is coming along, and how to contribute in the meantime?
[00:38] <pleia2> my blog post will be some overlap in that regard, but you're the expert in our base format :)
[00:38] <doctormo> pleia2: Expert you say :-)
[00:38] <doctormo> pleia2: OK I'll document it, perhaps it'll give me something to go to BiosElement with.
[00:38] <pleia2> well, you and bioselement are better than the rest of us ;)
[00:39]  * pleia2 nods
[00:39] <doctormo> cprofitt, meeting over?
[00:39] <cprofitt> unless there are other topics...
[00:39] <cprofitt> do you wish to motion to adjourn doctormo
[00:39] <pleia2> I'm done
[00:40] <cprofitt> I motion that we close the meeting
[00:40] <cprofitt> any seconds?
[00:40] <swoody> o/
[00:40] <cprofitt> any objections?
[00:40]  * swoody seconds
[00:40] <cprofitt> #endmeeting
[00:40] <MootBot> Meeting finished at 18:40.
[00:40] <pleia2> thanks everyone
[00:40] <cprofitt> thank you all for coming.
[00:41] <doctormo> thanks
[00:41]  * doctormo goes back to disney's aladin
[12:01] <Technoviking> morning all
[12:01] <pleia2> good morning
[12:01] <sabdfl> hello all
[12:01] <dholbach> good morning
[12:01] <dholbach> Technoviking: nice, you made it
[12:01] <dholbach> hey sabdfl, hi pleia2
[12:01] <dholbach> I'd say that's quorum already - who else do we have here?
[12:02] <sabdfl> Technoviking: morning :-)
[12:02] <dholbach> I have a bad internet connection here, can anybody else lead the meeting?
[12:03] <dholbach> AFAICS we have two agenda items on https://wiki.ubuntu.com/CommunityCouncilAgenda (no mdke here for the wiki licensing and U1 shouldn't really be on the agenda anymore)
[12:03] <popey> o/
[12:03] <dholbach> hey popey
[12:03] <pleia2> hey popey
[12:04] <dholbach> any volunteers for running the meeting? :)
[12:04] <sabdfl> i'm happy to do so
[12:04] <sabdfl> welcome, new CC
[12:04] <popey> Ahoi hoi!
[12:04] <sabdfl> can we remove the one.ubuntu.com item?
[12:05] <sabdfl> it was for information purposes, and everyone is now aware of it
[12:05]  * dholbach removes is
[12:05] <dholbach> it
[12:05] <sabdfl> ok. we're skipping the team wiki issue till mdke joins us
[12:05] <sabdfl> CoC - any thoughts before we move to a vote?
[12:06] <sabdfl> ok
[12:06] <sabdfl> daniel, can you drive the vote please?
[12:06] <sabdfl> my mootbotfu is not up to it
[12:06] <dholbach> #startmeeting
[12:06] <MootBot> Meeting started at 06:06. The chair is dholbach.
[12:06] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[12:07] <dholbach> [TOPIC] Proposed CoC changes
[12:07] <MootBot> New Topic:  Proposed CoC changes
[12:07] <dholbach> is http://bazaar.launchpad.net/~mako/ubuntu-codeofconduct/proposed-revision/files the right link?
[12:07] <popey> are we merely voting on its acceptance as the new CoC or its implementation?
[12:08] <sabdfl> just voting on the text
[12:08] <popey> ok
[12:08] <sabdfl> dholbach: technically we should point to a particular revision on the branch
[12:08] <dholbach> I don't think it's the right branch
[12:08] <Technoviking> dholbach: that point to revision 8, sabdfl made a 9th revision
[12:08] <dholbach> my internet is just so slow here
[12:08] <dholbach> so it takes me ages to find it
[12:09] <pleia2> http://bazaar.launchpad.net/~sabdfl/ubuntu-codeofconduct/proposed-revision/files/9
[12:09] <MootBot> LINK received:  http://bazaar.launchpad.net/~sabdfl/ubuntu-codeofconduct/proposed-revision/files/9
[12:09] <sabdfl> http://bazaar.launchpad.net/~mako/ubuntu-codeofconduct/proposed-revision/annotate/head%3A/CodeOfConduct.txt
[12:09] <pleia2> I think was the last
[12:09] <MootBot> LINK received:  http://bazaar.launchpad.net/~mako/ubuntu-codeofconduct/proposed-revision/annotate/head%3A/CodeOfConduct.txt
[12:09] <dholbach> can everybody double-check?
[12:09] <sabdfl> it was rev 9 on *my* branch, but mako merged it in as rev 8 on his
[12:09] <sabdfl> it's accurate as it stands
[12:09] <popey> http://bazaar.launchpad.net/~sabdfl/ubuntu-codeofconduct/proposed-revision/annotate/8/CodeOfConduct.txt
[12:09] <MootBot> LINK received:  http://bazaar.launchpad.net/~sabdfl/ubuntu-codeofconduct/proposed-revision/annotate/8/CodeOfConduct.txt
[12:10] <popey> gah
[12:10] <dholbach> sabdfl: so no diff between the two?
[12:10] <popey> http://bazaar.launchpad.net/~mako/ubuntu-codeofconduct/proposed-revision/annotate/8/CodeOfConduct.txt
[12:10] <MootBot> LINK received:  http://bazaar.launchpad.net/~mako/ubuntu-codeofconduct/proposed-revision/annotate/8/CodeOfConduct.txt
[12:10] <popey> that one?
[12:10] <sabdfl> dholbach: nothing material - the mako link is the correct one
[12:10] <dholbach> ok great
[12:10] <sabdfl> let's move to vote
[12:11] <dholbach> [VOTE] Do we approve http://bazaar.launchpad.net/~mako/ubuntu-codeofconduct/proposed-revision/annotate/head%3A/CodeOfConduct.txt as the new Code of Conduct?
[12:11] <MootBot> Please vote on:  Do we approve http://bazaar.launchpad.net/~mako/ubuntu-codeofconduct/proposed-revision/annotate/head%3A/CodeOfConduct.txt as the new Code of Conduct?.
[12:11] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[12:11] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[12:11] <sabdfl> well, no, that's the tip URL
[12:11] <sabdfl> but lets vote anyway
[12:11] <sabdfl> +1
[12:11] <MootBot> +1 received from sabdfl. 1 for, 0 against. 0 have abstained. Count is now 1
[12:11] <Technoviking> +1
[12:11] <MootBot> +1 received from Technoviking. 2 for, 0 against. 0 have abstained. Count is now 2
[12:11] <pleia2> +1
[12:11] <MootBot> +1 received from pleia2. 3 for, 0 against. 0 have abstained. Count is now 3
[12:11] <dholbach> +1
[12:11] <popey> +1
[12:11] <MootBot> +1 received from popey. 4 for, 0 against. 0 have abstained. Count is now 4
[12:11] <MootBot> +1 received from dholbach. 5 for, 0 against. 0 have abstained. Count is now 5
[12:11] <dholbach> [endvote]
[12:11] <MootBot> Final result is 5 for, 0 against. 0 abstained. Total: 5
[12:11] <dholbach> woohoo! :)
[12:11] <dholbach> nice
[12:11] <sabdfl> thanks all, we have an updated CoC
[12:12] <dholbach> I'm happy we finally did that :)
[12:12] <sabdfl> popey: want to talk implementation?
[12:12] <dholbach> hey mako
[12:12] <mako> sorry i'm a little late
[12:13] <sabdfl> np
[12:13] <sabdfl> mako, we just voted on and approved the new CoC per your rev 8
[12:13] <popey> I'd like to see a system whereby it's clear which verion of the CoC someone signed
[12:13] <sabdfl> agreed
[12:13] <mako> oh, wonderful
[12:13] <popey> and allow people to 'upgrade' their signature
[12:13] <dholbach> is there a launchpad bug/blueprint open for that?
[12:13] <mako> needless to say (and for the record), i am also in favor
[12:13] <popey> or elect not to
[12:13] <sabdfl> i believe this is tracked in LP already, but we don't have flows around upgrading or displaying it
[12:14] <sabdfl> popey: can you chat with curtis hovey about that?
[12:14] <popey> sure
[12:14] <sabdfl> he's in US timezones
[12:14] <sabdfl> i think the real plan is to generalise it, so any project can publish agreements / terms / sla's and we track who's agreed to what
[12:14] <popey> that would be useful
[12:15] <dholbach> that sounds great
[12:15] <dholbach> anything else on the topic of CoC?
[12:15] <sabdfl> sounds like a swamp of legalese to me, but hey, full speed ahead :-)
[12:15] <dholbach> :-)
[12:15] <popey> heh
[12:15] <sabdfl> dholbach: will you publish it in all the right places?
[12:15] <mako> that seems like a minor issue. and in general, we want to avoid having to deal with arguments like, "well, i only agreed to version 1.0 of the CoC, not 1.1"
[12:16] <popey> but we equally don't want people to say 'Hey, I never signed up for that!'
[12:16] <mako> that's certainly not a reason to not check
[12:16] <popey> GPL v2 or later ..
[12:16] <sabdfl> i would like to have a stab at generalising the CoC, so that other projects don't have to fork it
[12:16] <Technoviking> someone should publishize it to the Planet
[12:16] <dholbach> sabdfl: I'll talk to newz2000 to get it on ubuntu.com - not sure wherelse it needs to go
[12:16] <dholbach> sabdfl: but I'll have a look
[12:16] <sabdfl> so, that can be a goal for a CoC 2.0
[12:16] <sabdfl> Technoviking: go ahead and blog it!
[12:16] <pleia2> Technoviking: I can
[12:16] <pleia2> or you :)
[12:17] <dholbach> both!
[12:17] <dholbach> :)
[12:17] <sabdfl> for the moment, i think we're wrapped on that front
[12:17] <Technoviking> sweet
[12:17] <dholbach> cool
[12:17] <popey> heh fill the front page with verbatim copies of the CoC :)
[12:17] <pleia2> dholbach: can you let me know when you have it "published in all the right places"?
[12:17] <popey> (front page of the planet)
[12:17] <mako> sabdfl: ah! emma jane and i already have a branch where we started working on that
[12:17] <sabdfl> dholbach: want to introduce CommunityCouncil/Delegation/Proposal ?
[12:17] <dholbach> pleia2: will do - I'll file a bug and subscribe you
[12:17] <pleia2> dholbach: great, thanks!
[12:17] <dholbach> [TOPIC] Clarify expectations of Team Councils and Boards
[12:17] <MootBot> New Topic:  Clarify expectations of Team Councils and Boards
[12:17] <dholbach> sabdfl: sure
[12:18] <sabdfl> cool mako! i didn't have any great insight other than the need to generalise so if you're working on it i'm +1 and won't interfere
[12:18] <dholbach> we've grown a lot of team councils and boards in the Ubuntu community already and it seems like a good idea to clarify expectations for those governance bodies
[12:19] <dholbach> https://wiki.ubuntu.com/CommunityCouncil/Delegation/Proposal is very common, very simple steps to try to go forward and expect similar things of all of them
[12:19] <dholbach> if we can agree on it, I'd like to add merge https://wiki.ubuntu.com/CommunityCouncil/Delegation/Proposal  into https://wiki.ubuntu.com/CommunityCouncil/Delegation
[12:20] <sabdfl> i think it could be fleshed out a bit more
[12:20] <sabdfl> not sure if it's best for me to do that right now, or later
[12:20] <dholbach> sabdfl: what parts are you thinking of?
[12:20] <sabdfl> but i'd like to see more specific articulation of the general model:
[12:21] <sabdfl>  - governance boards (policy, dispute resolution)
[12:21] <sabdfl>  - ops (moderators in forums, ops in irc, general uploaders in the dev team, etc)
[12:21] <mako> dholbach: so i've seen this before and there's nothing in there that i find problematic
[12:21] <sabdfl>  - members (substantial contributors)
[12:22] <sabdfl> that's a structural pattern that isn't clear to me from this doc
[12:22]  * mako nods to sabdfl
[12:22] <sabdfl> it's not rigid, but i would like to see the pattern articulated somewhere
[12:22] <sabdfl> dholbach: will you lead the discussion while i have a stab at that in the document?
[12:22] <sabdfl> apologies for real-time editing :-/
[12:22] <dholbach> sure, that all sounds good to me
[12:23] <jono> I am happy to help with this too if needed, dholbach
[12:23] <dholbach> pleia2, Technoviking, popey: do you have any other comments on the proposal?
[12:23] <popey> no
[12:23] <pleia2> no, looks good
[12:23] <Technoviking> fine here
[12:25] <dholbach> I agree with sabdfl - having team councils approve members is a great way to build a community and recognise great contributions
[12:25] <jono> agreed
[12:25] <dholbach> and mentioning dispute resolution makes sense too
[12:25] <dholbach> I think we have a document about that on the wiki already
[12:25] <dholbach> something in the BuildingCommunity/ namespace?
[12:26] <dholbach> can somebody help me find it? maybe we could link to it as a "howto"
[12:26] <jono> about councils approving members?
[12:26] <dholbach> no, sorry, dispute resolution
[12:26] <jono> oh right
[12:26] <dholbach> for membership wiki.u.c/Membership should be good enough
[12:26] <jono> I remember writing something up about it a long time back
[12:26] <jono> I will see if I can find it
[12:27] <pleia2> https://wiki.ubuntu.com/CodeOfConductGuidelines links to an unratified Dispute Resolution document
[12:27] <dholbach> my internet is dog-slow here, so don't wait on me finding it :)
[12:27] <pleia2> https://wiki.ubuntu.com/CodeOfConductDisputeResolution
[12:28] <dholbach> https://wiki.ubuntu.com/BuildingCommunity/DealingWithConflict is what I was thinking of
[12:29] <mako> yeah, the second links looks a bit more threshed out
[12:29] <jono> dholbach, thats the doc I was thinking of too
[12:29] <dholbach> jono: I updated it a few weeks ago and linked it from a few other places too
[12:29] <jono> I could also take my conflict chapter from The art of community and put there there too
[12:29] <dholbach> sure, that'd be good
[12:30] <dholbach> so https://wiki.ubuntu.com/BuildingCommunity/DealingWithConflict looks good to all of you?
[12:31] <popey> yeah, I'd not seen that page before.. it's pretty good
[12:31] <dholbach> cool, it'd be good if we could refer to a "howto" from the delegation page
[12:31] <popey> could do with a couple of exit points for where the process fails
[12:32] <popey> e.g. 'get everyone on irc', if people refuse to join, or evade meetings.. what to do next
[12:32] <dholbach> maybe Jono's book chapter has more detail? :)
[12:33] <jono> dholbach, it does
[12:33] <jono> it talkes through a conflict resolution scenario too
[12:33] <dholbach> good
[12:33] <dholbach> I'm not so sure what sabdfl meant when he mentioned "policy" - so I'd wait for him to re-emerge from the wiki editing
[12:33] <jono> I will see if I can chop out the chapter and put it online
[12:33] <dholbach> thanks jono
[12:33] <jono> :)
[12:34] <dholbach> does anybody have thoughts about the structure of moderators in forums, ops in irc, general uploaders in the dev team, etc
[12:34] <dholbach> ?
[12:35] <jono> what do you mean?
[12:35] <dholbach> sabdfl:  mentioned it above
[12:35] <dholbach> err
[12:35] <dholbach> sabdfl mentioned it above
[12:35] <mako> i mean, i don't have any general comments beyond the fact that they should be people who can/do satisify the requirements laid out in the LCoC
[12:35] <pleia2> I'd need to hear more from the specific teams about what they think the structure should be
[12:36] <jussi01> Thats a pretty broad group there.
[12:36] <sabdfl> take a look at what's there now, folks, is it headed in the right direction?
[12:37] <dholbach> https://wiki.ubuntu.com/CommunityCouncil/Delegation/Proposal?action=diff&rev2=8&rev1=6
[12:37] <jono> sabdfl, looks good to me
[12:38] <jono> I feel like we also need to link to a page detailing meeting best practise
[12:38] <jono> how to run a meeting, essentially
[12:38] <jono> we can check into this
[12:39] <sabdfl> ok, i will finish this edit in a while if you are all happy with the direction
[12:39] <pleia2> these changes look good so far
[12:39] <dholbach> https://wiki.ubuntu.com/BuildingCommunity/TeamReporting https://wiki.ubuntu.com/Membership https://wiki.ubuntu.com/BuildingCommunity/TeamIrcSessions probably
[12:39] <Technoviking> looks good to me
[12:39] <dholbach> sabdfl: I'm happy with it too
[12:39] <sabdfl> i will include those links, dholbach
[12:39] <dholbach> super
[12:40] <jono> sounds good
[12:40] <mako> best practice stuff is great. councils should have as many of those sorts of resources
[12:40] <dholbach> https://wiki.ubuntu.com/BuildingCommunity/KnowledgeBase has a lot of good stuff :)
[12:40] <jono> indeed :)
[12:40] <mako> but we should be clear to distinguish best practices from policies and guidelines. our guidlines should be as small as possible and as reactive as we can
[12:40] <dholbach> maybe we should also mention the team-council mailing list or whatever it's called?
[12:41] <dholbach> mako: agreed, that should be clear
[12:41] <sabdfl> i think it's already there, i'll bolster it a little
[12:41] <jussi01> Just one thing slightly related to that delegation page, (if its inappropriate for now pull me up) is there a reason we only get people to sign the CoC and not sign the LCoC?
[12:41] <jono> dholbach, it is in there
[12:42] <dholbach> jono: ok cool
[12:42] <jono> I am planning a few posts there this week
[12:42] <dholbach> jussi01: I'm happy to take somebody's "word of honour" for it as soon as they step up as a leader
[12:42] <dholbach> I personally don't think we need a technical implementation for it
[12:42] <pleia2> at the end of the the CoC there is a clause about leaders being required to follow the LCoC
[12:42] <dholbach> ah cool :)
[12:43] <jussi01> oh, I didnt notice that. :)
[12:43] <dholbach>  #include <lcoc>    :-)
[12:43] <jussi01> hehe
[12:43] <dholbach> maybe a word about sharing best-practices on https://lists.ubuntu.com/mailman/listinfo/team-council-members ?
[12:43] <dholbach> but maybe that's too obvious :)
[12:44] <jono> dholbach, indeed
[12:44]  * popey wasnt aware of that list
[12:44] <jono> I would like to encourage people to use that list as a means of sharing best practice as well as asking for help with governance issues
[12:44] <jono> popey, this reminds me, we need to ensure the new CC is on
[12:44] <pleia2> popey: I wasn't either :)
[12:45] <jono> popey, it is a list for Ubuntu community governance board members
[12:45] <jono> pleia2, popey I will add you if that is ok?
[12:45] <pleia2> jono: yes, thank you
[12:45] <jono> np
[12:46] <dholbach> anything else you want to include/change on  https://wiki.ubuntu.com/CommunityCouncil/Delegation/Proposal ?
[12:46] <popey> jono: sure
[12:46] <jono> cool
[12:46] <popey> alan@popey.com
[12:46] <jono> dholbach, looks good, I think it hits the main points
[12:46] <jussi01> dholbach: you may want to actually ad the address for the tem council list there? or a link to the lists.ubuntu.com page for it
[12:47] <dholbach> jussi01: I think sabdfl is editing right now
[12:50] <sabdfl> ok, take a look now
[12:50] <sabdfl> sorry for the deep dive on the doc
[12:50] <dholbach> https://wiki.ubuntu.com/CommunityCouncil/Delegation/Proposal?action=diff&rev2=9&rev1=6
[12:51] <jono> this looks good sabdfl
[12:52]  * dholbach fixes a typo and adds https://lists.ubuntu.com/mailman/listinfo/team-council-members
[12:52] <jono> sorry folks, I need to run back to the apartment, ready for my call with dholbach in 8mins
[12:52] <jono> I will be back soon
[12:54] <dholbach> I'm happy with it
[12:54]  * dholbach waits for it to save
[12:54] <dholbach> if nobody spots anything urgent, shall we proceed to vote?
[12:54] <dholbach> https://wiki.ubuntu.com/CommunityCouncil/Delegation/Proposal?action=diff&rev2=10&rev1=9 is my last edit
[12:55] <dholbach> sabdfl, mako, popey, pleia2, Technoviking: anything else? ready to vote?
[12:55] <popey> ij
[12:55] <popey> er, ok
[12:55] <Technoviking> looks great to me
[12:56] <sabdfl> ready
[12:56] <mako> yeah, still going over it
[12:56] <pleia2> needs to be reviewed for typos ("can he ha helpful guide"), but otherwise looks good
[12:56] <mako> yeah, this looks great
[12:57] <dholbach> [VOTE] Approve https://wiki.ubuntu.com/CommunityCouncil/Delegation/Proposal for all Ubuntu Team Councils and Boards?
[12:57] <MootBot> Please vote on:  Approve https://wiki.ubuntu.com/CommunityCouncil/Delegation/Proposal for all Ubuntu Team Councils and Boards?.
[12:57] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[12:57] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[12:57] <dholbach> +1
[12:57] <MootBot> +1 received from dholbach. 1 for, 0 against. 0 have abstained. Count is now 1
[12:57] <pleia2> +1
[12:57] <MootBot> +1 received from pleia2. 2 for, 0 against. 0 have abstained. Count is now 2
[12:57] <Technoviking> +1
[12:57] <MootBot> +1 received from Technoviking. 3 for, 0 against. 0 have abstained. Count is now 3
[12:57] <popey> +1
[12:57] <MootBot> +1 received from popey. 4 for, 0 against. 0 have abstained. Count is now 4
[12:58] <dholbach> sabdfl? :)
[12:58] <sabdfl> +1
[12:58] <MootBot> +1 received from sabdfl. 5 for, 0 against. 0 have abstained. Count is now 5
[12:58] <dholbach> [endvote]
[12:58] <MootBot> Final result is 5 for, 0 against. 0 abstained. Total: 5
[12:59] <dholbach> thanks a lot everybody and thanks sabdfl for that fast editing! :)
[12:59] <sabdfl> i think that concludes the agenda
[12:59] <dholbach> does anybody of you have anything else to discuss?
[12:59] <mako> +1
[12:59] <mako> too late :)
[12:59]  * dholbach needs to rush off for a call in a sec
[12:59] <dholbach> mako: oh sorry
[12:59] <mako> it's ok :)
[12:59] <mako> it's in the log
[12:59] <sabdfl> alright, thank you all, look forward to seeing you again soon
[12:59] <dholbach> yeah :)
[13:00] <dholbach> thanks a lot everybody
[13:00] <sabdfl> thanks to those who got up extra early today :-)
[13:00] <dholbach> yeah :-)
[13:00] <sabdfl> thanks dholbach and jono for preparing much of this for us
[13:00] <Technoviking> thanks all , fantastic meeting
[13:00] <dholbach> if nobody else does it, I'll do minutes later on
[13:00] <pleia2> thanks everyone
[13:00] <sabdfl> cheers all
[13:00] <dholbach> (might take a bit
[13:00] <dholbach> )
[13:00] <dholbach> #endmeeting
[13:00] <MootBot> Meeting finished at 07:00.
[13:00] <dholbach> bye
[13:00] <popey> o/
[13:01] <czajkowski> nicely done :)
[13:02] <mako> thanks everyone :)
[13:58] <lool> Hi
[13:58] <NCommander> morning
[13:58]  * NCommander is here for now, but will not chair since I will be running before the meeting concludes
[13:59] <ogra> i'll chair as i said
[13:59] <NCommander> Just saying :-)
[14:00] <ogra> #startmeeting
[14:00] <MootBot> Meeting started at 07:59. The chair is ogra.
[14:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[14:00] <ogra> dyfet, plars, GrueMaster, JamieBennett, StevenK, lool, paulliu, NCommander
[14:00] <ogra> ping ! :)
[14:00]  * NCommander waves
[14:00]  * plars is here, full throttle in hand
[14:00] <ogra> davidm, are you attending ?
[14:00] <dyfet> hi
[14:00] <JamieBennett> hey
[14:01] <davidm> ogra, I am
[14:01]  * ogra waits for StevenK and lool attention bits :)
[14:01]  * StevenK shores
[14:01] <ogra> ah :)
[14:01] <ogra> [topic] Action item review
[14:01] <MootBot> New Topic:  Action item review
[14:01] <ogra> StevenK to look into UNR ISO size tweaks
[14:01]  * GrueMaster has coffee, will snooze^h^h^h be alert.
[14:02] <paulliu> hi
[14:02] <NCommander> I can't pull up the wiki :-/
[14:02] <ogra> StevenK, how does it look
[14:02] <plars> ogra: links?
[14:02] <ogra> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20091020
[14:02] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20091020
[14:02] <StevenK> The UNR ISO is currently 680MB, I was going to add de
[14:02] <ogra> \o/
[14:02] <ogra> good move !
[14:03] <ogra> sounds good then
[14:03] <ogra> - lool to file a bug about armel fsck issues
[14:03] <lool> I dont remember that bug  :-(
[14:04]  * ogra tries to find something ... 
[14:05] <lool> Oh I think I filed it
[14:05] <lool> During the meeting
[14:05] <ogra> hmm, cant find something either
[14:05] <ogra> which one is it ? my evolution keeps quiet on searches
[14:06] <ogra> weird
[14:06] <lool> ogra: Oh it wasn't fsck
[14:06] <ogra> well, lets move on and dig after the meeting
[14:06] <lool> I dont know why you said that last week
[14:06] <lool> It was binfmt_misc
[14:06] <ogra> oh
[14:06] <lool> I filed 450363 and it was resolved
[14:06] <lool> [14:20] <lool> amitk: I didn't have a chance to report it, but binfmt_misc sseems to be missing in dove
[14:07] <ogra> i think you pasted a log and i just grabbed fsck out there
[14:07] <lool> [14:21] <ogra> lool, are you trying to run a karmic ext4 fs with a jaunty kernel ?
[14:07] <ogra> before we discussed it
[14:07] <ogra> yeah
[14:07] <lool> For some reason you seemed to believe that was fsck related but it's not
[14:07] <ogra> sorry, my failt
[14:07] <ogra> *fault
[14:07] <ogra> ok
[14:07] <ogra> - plars to move UNR bugs from non-karmic to karmic where necessary
[14:07] <lool> Don't worry, I an blaming you!   :-)
[14:07] <lool> *am
[14:07] <ogra> phew, lucky me :P
[14:07] <plars> seems I can still nominate bugs but not actually accept them
[14:08] <plars> I nominated a few more, but I need to talk to the QA guys again about getting the ability to do that
[14:08] <ogra> can you give a list to someon who can ?
[14:08] <plars> for now, best to look at the subscribed list
[14:08] <ogra> ok
[14:08] <plars> for ubuntu-unr team
[14:08] <plars> focus on high/critical
[14:08] <ogra> so we come to the intresting action items :)
[14:09] <ogra> - new rolling action: everyone with upload privs to look inot sponsoring bugs next week and report which ones he closed
[14:09] <ogra> i sponsored the fis for bug 445358
[14:09] <ogra> *fix
[14:09] <ogra> nothing more sadly :/
[14:10] <ogra> lool, StevenK, what did you guys sponsor this week ? :)
[14:10] <lool> Well it's Jamie's
[14:10] <ogra> its a sponsoring upload
[14:10]  * lool marks a big one in ogra's box and a small zero in hi
[14:10] <lool> his
[14:10] <ogra> heh
[14:11] <StevenK> ogra: I uploaded jijget (or so) for maco
[14:11] <ogra> StevenK, did you do any sponsoring ?
[14:11] <ogra> ++
[14:11] <ogra> cool
[14:11] <StevenK> I was trying to remember how to spell it, and failed
[14:11] <StevenK> So I guessed
[14:11] <ogra> well, at least we have something on the list
[14:11] <ogra> lets improve that ;)
[14:12] <ogra> ok ...
[14:12] <ogra> - anyone who has spare test cycles to test lool's ffmpeg packages
[14:12]  * ogra shamefully hans his head 
[14:12] <ogra> *hangs too ...
[14:12] <ogra> did anyone test the packages ?
[14:12] <lool> Yes
[14:12] <StevenK> If that's an arm package, ENOHARDWARE
[14:12] <ogra> apart from the producer i mean :)
[14:12] <GrueMaster> I did some testing.  I don't have a lot of test videos, but what I do have seemed to play ok, even from an NFS share.
[14:13] <lool> I asked for testing on any arch and got some
[14:13] <ogra> StevenK, right, but dyfet NCommander plars JamieBennett or GrueMaster could test
[14:13] <lool> plars reported that performance did not improve on non-NEON hardware which is ok
[14:13]  * NCommander hangs his head
[14:13] <lool> and it was pushed to karmic so it is sufficiently tested at this point
[14:13] <ogra> ok
[14:14] <ogra> anything we need to do about past specs in the spec review topic ?
[14:14] <ogra> [topic] spec review
[14:14] <MootBot> New Topic:  spec review
[14:14] <ogra> who has ideas for lucid and wants to share ?
[14:14] <NCommander> ext2 images versus vfat
[14:15] <ogra> * casper cleanup/speedup
[14:15] <StevenK> On arm?
[14:15] <NCommander> hardware based system recovery
[14:15] <StevenK> Stacked livefses
[14:15] <NCommander> StevenK, in general, but mostly targetted for ARM
[14:15] <ogra> * stacked squashfs builds for live images (separate rootfs and kernel/modules completely)
[14:15] <NCommander>  * clean up d-cd armel backends to remove a ton of code duplication between imx51 and dove
[14:15] <ogra> oh, StevenK beats me :)
[14:15]  * StevenK beats ogra 
[14:16] <NCommander>  * ARM Softbootloader (again)
[14:16] <StevenK> Application changes for UNR
[14:16] <ogra> * my personal one: move debian-cd for imx51 completely to redboot-tools
[14:16] <StevenK> Session changes for UNR
[14:16] <StevenK> Moblin Remix Revisited
[14:16] <NCommander>  * UNR for ARM revisited
[14:16] <ogra> will we revisit it ?
[14:16] <ogra> (moblin)
[14:16] <ogra> davidm, ^^ ?
[14:17] <NCommander> Well, in either case, we still need to figure out how we're going to handle Moblin for Lucid
[14:18] <ogra> *if* we handle it we have to, yes
[14:18] <davidm> We will need to revisit, likely with a 2D launcher
[14:18] <JamieBennett1> not sure what happened there
[14:18] <ogra> davidm, moblin with a 2D launcher ?
[14:19] <davidm> UNR with 2D launcer sorry
[14:19] <davidm> UMR is up in the air
[14:19] <ogra> ok
[14:19] <ogra> lool, you said you had a list with spec suggestions too
[14:19] <GrueMaster> There is a high possibility that we will be seeing PSB drivers again in that time frame.
[14:19] <lool> Please let us use "moblin remix" not UMR
[14:20] <NCommander> GrueMaster, ?
[14:20]  * StevenK sobs
[14:20] <persia> Last cycle, there was https://wiki.ubuntu.com/MobileTeam/KarmicSpecifications : why not do the same forhttps://wiki.ubuntu.com/MobileTeam/LucidSpecifications ?
[14:20] <GrueMaster> Inside info.
[14:20]  * lool uploads http://paste.ubuntu.com/297486/
[14:20] <persia> And review the suggestions everyone adds there one-by-one next week.
[14:20] <ogra> persia, btw, any suggestions
[14:21] <ogra> (assuming you return in lucid)
[14:21] <dyfet> I had put up one spec for broader discussion, but it is VoIP related, and not mobile centric
[14:21] <StevenK> dyfet: No LXDE stuff?
[14:21] <persia> ogra, Assuming I have time, I'd like to improve desktop/handheld interaction stuff.
[14:21] <dyfet> I am going to have a LXDE one done in large part from the community
[14:24] <ogra> http://paste.ubuntu.com/297492/
[14:24] <MootBot> LINK received:  http://paste.ubuntu.com/297492/
[14:24] <ogra> thats what i stripped out of the discussion
[14:24] <ogra> so everyone please add specs to https://wiki.ubuntu.com/MobileTeam/LucidSpecifications until next meeting
[14:24] <ogra> [link] https://wiki.ubuntu.com/MobileTeam/LucidSpecifications
[14:24] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/LucidSpecifications
[14:25] <ogra> anything else for specs ?
[14:25] <StevenK> ogra: By name?
[14:25] <StevenK> ogra: Or just list them?
[14:25] <GrueMaster> Someone needs to make the LucidSpecifications wiki to start with.
[14:25] <ogra> i think we should just list them for now
[14:25] <lool> StevenK: progress on ISO size bits for UNR?
[14:26] <ogra> GrueMaster, the first one who gets there i'd say :P
[14:26] <NCommander> I have an update with dove
[14:26] <StevenK> lool: UNR is 680, I don't think I can shrink it
[14:26] <ogra> lool, covered at the beginning
[14:26] <StevenK> lool: I was going to add de/fr
[14:26] <ogra> ok, lets move on
[14:26] <plars> bringup test procedures for new hardware, and documentation of what works/doesn't, workarounds, etc
[14:26] <ogra> [topic] UNR Status
[14:26] <MootBot> New Topic:  UNR Status
[14:26] <NCommander> partman-uboot was merged and intergrated (thank you cjwatson). I smoke tested it, but I haven't tested one of today's dailies
[14:26] <ogra> so StevenK anything intresting beyond size reduction ?
[14:27] <StevenK> Testing!
[14:27] <StevenK> Lots of testing!
[14:27] <ogra> indeed !!!
[14:27] <NCommander> Look, I got ot run, my gate may have changed.
[14:27] <StevenK> RC is this week!
[14:27] <NCommander> or not
[14:27] <ogra> all for UNR ?
[14:27] <ogra> ok
[14:28] <lool> netbook-launcher upload
[14:28] <ogra> [topic] moblin remix Status
[14:28] <MootBot> New Topic:  moblin remix Status
[14:28] <lool> and notify-osd upload
[14:28] <lool> but it's basically ok
[14:28] <StevenK> I'd like to upload casper
[14:28] <ogra> paulliu, so how does moblin look ?
[14:29] <StevenK> But I need to build an initrd that isn't broken
[14:29] <paulliu> ogra: Just left some minor bugs.
[14:29] <ogra> runs and installs ?
[14:29] <plars> haven't looked at the new image this morning yet, but according to lool the apt popup error should be fixed now
[14:29] <paulliu> And those bugs are upstream bugs.
[14:29] <GrueMaster> Moblin Compliance testing failures down to 165, mostly programmatic errors at this point.
[14:29] <lool> We just have a new image published
[14:29] <paulliu> ogra: yes.
[14:29] <ogra> cool !!!
[14:29] <ogra> so pretty much on track it seems
[14:29] <StevenK> GrueMaster: Our errors?
[14:30]  * ogra doesnt have errors
[14:30] <paulliu> Moblin 2.1 preview is updated by Intel again. However we've freezed so not going to update the versions.
[14:30] <paulliu> It changes a lot.
[14:30] <GrueMaster> Don't know.  I am seeing the same errors on the LSB testing.  I think a lot of them are actually in the tests.
[14:30] <plars> GrueMaster: where are this posted? the last results I see say 173
[14:30] <NCommander> GrueMaster, check the LSB sight to see what tests have errata and/or waviers
[14:30] <NCommander> *site
[14:30] <paulliu> ABI/API bump in foundation libraries.
[14:30] <GrueMaster> I will upload the new results this morning.
[14:30] <plars> GrueMaster: also, I don't recall, was there a comparison run with upstream moblin?
[14:30] <paulliu> So we are going to establish another PPA. OEM team have to update all the packages before this week.
[14:30] <GrueMaster> This is from Friday test run.
[14:30] <plars> GrueMaster: cool, thanks
[14:31] <lool> paulliu: god  :-(
[14:31] <ogra> oh my
[14:31] <StevenK> paulliu: Argh!
[14:31] <StevenK> paulliu: Why?
[14:31] <NCommander> paulliu, OW
[14:31] <NCommander> paulliu, I do hope that the soversions and friends have been properly bumped
[14:31] <paulliu> Don't worry. Personally I'll update Debian packages with OEM team so in Lucid we'll have newer versions.
[14:31] <GrueMaster> I haven't had a chance to run a comparison with upstream, mainly because they are missing a lot of necessary bits from their repository.
[14:31] <lool> It seems we didn't cover the UNR nor the moblin bugs
[14:32] <plars> GrueMaster: that's a decent improvement from the previous, was that due to config changes, additional packages you installed, fixes made in the packages? what?
[14:32] <lool> [link] https://bugs.launchpad.net/ubuntu/karmic/+bugs?field.subscriber=ubuntu-unr
[14:32] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/karmic/+bugs?field.subscriber=ubuntu-unr
[14:32] <lool> njpatel: dbarth wanted to tentatively poke this UNR bug
[14:32] <paulliu> NCommander: yes. soname is bumped. So package name bumped too..
[14:32] <NCommander> paulliu, that's good; it could be worse.
[14:32] <GrueMaster> Adding sym links to some newer libraries actually.
[14:32] <lool> njpatel: There are a unch of fix committed or in progress bugs on https://bugs.launchpad.net/~ubuntu-unr which seem like they probably should be fix released
[14:32] <StevenK> GrueMaster: That isn't a solution
[14:33] <GrueMaster> Some libraries are backwards compatible with older versions.
[14:33] <ogra> *some*
[14:33] <ogra> ...
[14:33] <GrueMaster> Some aren't, which caused more failures.  I ran a libcheck test on this before launching the main test run.
[14:33] <paulliu> GrueMaster: Ah. I'm sure it doesn't backward compatible. If updates that library, things are FTBFS.
[14:33] <paulliu> GrueMaster: So we have to update those stuff together.
[14:34] <lool> [link] https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-moblin
[14:34] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-moblin
[14:34] <njpatel> lool: I'll catch up with dbarth on the keyring bug
[14:34] <lool> paulliu: I'm a bit worried with the cheer number of sync bugs there
[14:34] <lool> paulliu: Shall we close them to prevent them from happening?
[14:34] <njpatel> lool: I need to make a clutk release that will fix the allocation crashes, will do that before end of today
[14:34] <njpatel> lool: sorry, that will fix-release the crashers
[14:34] <lool> njpatel: Ok thanks
[14:35] <paulliu> lool: Yes. We should close them now. I found it tries to sync the newer version in Debian which I just upload for OEM team.. :(
[14:35] <lool> paulliu: Could you close them?
[14:35] <paulliu> lool: Yes. I'll do that after the meeting.
[14:35] <ogra> [action] paulliu to close remaining moblin sync bugs for karmic
[14:35] <MootBot> ACTION received:  paulliu to close remaining moblin sync bugs for karmic
[14:35] <plars> njpatel: excellent, that should fix all of them? shall I dup them all to one so that you can just tag it with that lp#, or are they actually separate problems?
[14:35] <lool> StevenK: I assigned you to 439656 and marked it as triaged
[14:35] <lool> StevenK: mark it in progress if you're working on it
[14:36] <ogra> are we done with moblin/UNR status ? ....
[14:36] <ogra> [topic] armel status
[14:36] <MootBot> New Topic:  armel status
[14:36] <lool> [link] https://bugs.launchpad.net/ubuntu-moblin-remix/+bugs
[14:36] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu-moblin-remix/+bugs
[14:37] <njpatel> plars: I believe it'll fix the _allocate crashers and the screwup with the rows of icons (overlapping and bogus spaces)
[14:37] <lool> plars, GrueMaster: Would probably help if more bugs had an importance on the above list, but I read through them as they came in and don't recall a lot of scary things
[14:37] <njpatel> plars: I was using this https://bugs.edge.launchpad.net/clutk/+bug/445995 for _allocate issues
[14:37] <plars> lool: those are moblin, not armel
[14:37] <lool> plars: I know, I had the URL ready when ogra moved to armel
[14:37] <lool> I can't help it if he moves faster than I type  :-)
[14:38] <ogra> well, thats why i asked if you are done :P
[14:38] <plars> ah, ok :) and yes, agreed, will try to pick through them a bit, but moblin has been further down on my list lately
[14:38] <lool> ogra: in the same minute, you asked, moved on, and I posted the URL; I dont care
[14:38] <lool> please continue
[14:38] <GrueMaster> lool: We will triage these as fast as we can, but we can only juggle so much.
[14:38] <lool> ogra: It would help if as part of discussing each topic you posted bugs URLs though
[14:38] <ogra> ok, armel status ... NCommander ? how does dove look like ?
[14:39] <NCommander> ogra, partman-uboot was merged in by cjwatson last night
[14:39] <ogra> https://bugs.launchpad.net/ubuntu/karmic/+bugs?field.subscriber=ubuntu-armel
[14:39] <lool> [link] https://bugs.launchpad.net/ubuntu/karmic/+bugs?field.subscriber=ubuntu-armel
[14:39] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/karmic/+bugs?field.subscriber=ubuntu-armel
[14:39] <ogra> pfft
[14:39] <NCommander> ubiquity and partman-auto was also changed
[14:39] <NCommander> Both imx51 and dove images should be heavily tested. I don't except any unusual breakage, but its a fairly large change (especially this late)
[14:39] <lool> NCommander: do you cover bootrom and uboot updates in the install doc?
[14:39] <ogra> NCommander, great, did you test it very very hard before it was committed ?
[14:40] <NCommander> ogra, several test installs, but I'm just one person
[14:40] <ogra> indeed
[14:40] <NCommander> lool, I updated it to the previous drop we got from Marvell. I have to poke it for 4.3.1
[14:40] <NCommander> (which I haven't seen a stable drop of yet)
[14:40] <ogra> imx51 netinst has issues with dhclient and the FEC driver
[14:41] <ogra> imx51 alternate has bug 360925
[14:41] <NCommander> lool, dyfet ran through the instructions end to end, made sure they work. I also standardized Y0 and Y1 boot methods
[14:41] <ogra> (i suspect dove has the same issue)
[14:41] <lool> NCommander: did you report to marvell on testing of their uboot?
[14:41] <NCommander> lool, yes I did
[14:41] <dyfet> I tested Y0 of course, but yes, it worked
[14:41] <lool> ogra: what's the bug for the dhclient issue?
[14:41] <ogra> no bug yet, i'll file it later today
[14:41] <lool> About time
[14:42] <ogra> [action] ogra to file a bug for dhclient not working properly with the FEC driver in d-i
[14:42] <MootBot> ACTION received:  ogra to file a bug for dhclient not working properly with the FEC driver in d-i
[14:42] <NCommander> As a heads up this week, I don't have my boards setup, I brought them withme in case the shit hits the fan, but unless needed, I do not plan to have them up and running so I'm not going to be available for ARM image testing
[14:42] <NCommander> Anyway
[14:42] <NCommander> time for me to board
[14:42] <lool> NCommander: Good thanks
[14:42] <NCommander> lool, I'll be back online in 1h-1:30 based on flight time.
[14:43] <NCommander> anyway
[14:43] <ogra> and as a reminder i'm on the roda from tomorrow on, imx51 testing needs to be done by others until monday
[14:43] <ogra> but i dont expect any regressions here, desktop works definately fine
[14:43] <JamieBennett1> ogra: I can do some testing
[14:43] <ogra> netinst and alternate work with some tinkering
[14:43] <plars> so can I
[14:43] <ogra> cool, thanks
[14:44] <GrueMaster> same here.  I have both Y0 & Y1.
[14:44] <ogra> and babbage :)
[14:44] <JamieBennett1> looks like we have it covered then :)
[14:44] <GrueMaster> yea, that too.
[14:44] <lool> can we close bug #450940?
[14:44] <ogra> great
[14:44] <cjwatson> note I made some corrections to NCommander's ubiquity changes, so it does need further testing
[14:45] <plars> GrueMaster: have you tried the recent images on Y0 to see if that's still a problem?
[14:45] <cjwatson> with specific attention to the behaviour of the mountpoint drop-down when creating or editing uboot partitions in ubiquity's manual partitioner
[14:45] <GrueMaster> The Y0 I have has the updated firmware and wasn't a problem to begin with.
[14:45] <GrueMaster> I traded with Brad last week.
[14:46] <lool> I'll go ahead and close 450940
[14:46] <ogra> ++
[14:46] <plars> cjwatson: thanks for the heads up, we should take a look at the partman stuff this week anyway since it just changed
[14:46] <lool> GrueMaster, plars: You guys tested suspend resume on imx51 as well?
[14:46] <GrueMaster> not yet.
[14:47] <plars> lool: I haven't yet, but my suspicion is that it does not resume
[14:47] <plars> had to borrow parts to work on dove, so my b2.5 is down, bringing it back to life today
[14:47] <ogra> [action] GrueMaster and plars to test suspend/resume on babbage and report results
[14:47] <MootBot> ACTION received:  GrueMaster and plars to test suspend/resume on babbage and report results
[14:48] <lool> plars: IMO do order enough parts that you can test the two at the same time; check with davidm but I think it's going to be important for release that we can test quickly multiple platforms at the same time
[14:48] <GrueMaster> I'll try to get to it.  My babbage has been focusing on the sata issue lately, but I can move the drive to a usb cable.
[14:48] <NC|Mobile> back
[14:48] <plars> lool: right, I had to make an unexpected  change
[14:48] <ogra> soo, is that all for armel ...
[14:48] <GrueMaster> lool: I agree.  I have 7 systems at my desk right now, all of which are accessible.
[14:48] <ogra> lool, speak up !
[14:48] <lool> GrueMaster: You can test suspend resume from cmdline if you like  :)
[14:49] <GrueMaster> Better to test with gui.
[14:49] <lool> Well I think nobody is chasing the toolchain issues except doko
[14:49] <GrueMaster> More involved.
[14:49] <davidm> plars, order parts to have both boards up and running
[14:49] <ogra> suspend should work from livefs
[14:49] <lool> Would be nice if someone could research the various toolchain issues on the list
[14:49] <ogra> hibernate needs an install
[14:50] <lool> dyfet: Which bugs are you working on ATM?
[14:51] <ogra> dyfet, *?
[14:52] <dyfet> I am going to close 453159 and 438450 today
[14:52] <dyfet> and add and close a bug for pigdin-sipe
[14:52] <lool> bug 453159
[14:52] <lool> bug 438450
[14:53] <lool> dyfet: Ok
[14:53] <dyfet> and the sipe one needs to be added :)...I will report it when I post the patch
[14:53] <GrueMaster> I am going to retest imx51 and see if bug #424400 can be closed.
[14:53] <lool> dyfet: these two are in universe though; perhaps you should focus on stuff in main first
[14:54] <NC|Mobile> door been closed. gtg
[14:54] <ogra> there was a new banshee upload this week
[14:54] <lool> Quick announce: I pushed armel cross compilers to my PPA
[14:54] <dyfet> lool: true, but they looked like they would be quick to resolve and were arm specific
[14:55] <ogra> dyfet, could you test the recent banshee ? it might fix issues
[14:55] <dyfet> ogra: yes...and I wonder if we still get divergent results :)
[14:55] <lool> ogra: I had the same stacktrace just installing a -cil package so I doubt it will be enough to resolve the mono issues
[14:55] <ogra> [action] dyfet to test recent banshee release and report to the banshee bug
[14:55] <MootBot> ACTION received:  dyfet to test recent banshee release and report to the banshee bug
[14:55] <ogra> lool, i havent
[14:56] <ogra> (as i reported on the bug)
[14:56] <ogra> anyway
[14:56] <lool> I did
[14:56] <ogra> are we done with armel ?
[14:56] <ogra> anything to add ?
[14:56]  * lool is done
[14:56] <ogra> [topic] AOB
[14:56] <MootBot> New Topic:  AOB
[14:56] <StevenK> Yes, it's 1am, and I'd like to sleep. :-P
[14:57] <GrueMaster> Any news on the imx51 sata issue?
[14:57] <ogra> nope
[14:57] <ogra> call is tonight
[14:57] <GrueMaster> (sorry, ogra types fast).
[14:57] <JamieBennett1> StevenK, orgra: AR's!
[14:57] <ogra> whoops
[14:57] <ogra> will do after the meeting
[14:57] <lool> GrueMaster: We confirmed that it is a kernel bug and that the gnome-session test case is enough to reproduce for kernel folks
[14:57] <GrueMaster> crack that whip.
[14:57] <StevenK> JamieBennett1: Will send before sleepy-time
[14:57] <ogra> GrueMaster, we will
[14:57] <lool> GrueMaster: So the ball is in the kernel camp; hopefully FSL can help figure out a fix here
[14:57] <GrueMaster> cool
[14:58] <ogra> 2 mins left ... any other AOB stuff ?
[14:58] <ogra> going once ...
[14:58] <ogra> going twice ...
[14:59] <ogra> #endmeeting
[14:59] <MootBot> Meeting finished at 08:59.
[14:59] <ogra> thanks all
[14:59] <GrueMaster> sold to the lady with the pink tutu.
[14:59] <ogra> :)
[14:59] <plars> with 1 min to spare, woot!
[14:59] <GrueMaster> oh, sorry.  Must be the coffee.
[15:01] <Keybuk> #startmeeting
[15:01] <MootBot> Meeting started at 09:01. The chair is Keybuk.
[15:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:01] <Keybuk> [LINK] https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:01] <MootBot> LINK received:  https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:01] <Keybuk> mdz, cjwatson, kees: ping?
[15:02] <mdz> Keybuk: pong
[15:03] <kees> \o
[15:04] <Keybuk> ok, that's three
[15:04] <Keybuk> we have a pretty short agenda today I think
[15:04] <Keybuk> [TOPIC] Developer Membership Board
[15:04] <MootBot> New Topic:  Developer Membership Board
[15:05] <kees> Keybuk: review actions from last meeting first?
[15:05] <Keybuk> kees: I can't find them, doesn't look like pitti sent them out?
[15:05] <kees> https://wiki.ubuntu.com/TechnicalBoard/TeamReports/Current
[15:05] <kees> # Keybuk to finalize unit policy and email to TB for vote
[15:05] <kees> # cjwatson to drive vote on Archive Reorg rights for ubuntu-desktop and mythbuntu in email
[15:05] <kees> # pitti to announce DMB meeting next Tuesday 1400
[15:06] <Keybuk> ah, thanks
[15:06] <Keybuk> (pitti should mail them too)
[15:06] <Keybuk> units policy is already on the agenda
[15:06] <Keybuk> cjwatson is not here (but has done both of those action points)
[15:06] <Keybuk> DMB meeting took place, so pitti's agenda item is cleared
[15:06] <Keybuk> :p
[15:06]  * kees nods
[15:06] <Keybuk> [TOPIC] Developer Membership Board
[15:06] <MootBot> New Topic:  Developer Membership Board
[15:07] <Keybuk> We had the first meeting, and subsequent meetings will take place as needed
[15:07] <Keybuk> ML is set up, and I saw the ML request go to RT for the private list
[15:07] <bdrung> FYI i am here for units policy
[15:07] <kees> hi bdrung, thanks
[15:07] <Keybuk> and the MC now send their reviews to the DMB
[15:07] <Keybuk> I think we can consider this complete, modulo documentation changes
[15:07] <Keybuk> jono: you took the action for those, how's that going?
[15:08] <pitti> o/ (sorry for being late)
[15:08] <jono> Keybuk, sorry, which actions?
[15:08] <kees> pitti: np, just reviewed actions, and now covering last item of DMB
[15:08] <Keybuk> jono: updating governance documentation to reflect that the DMB is now handling developer applications, not the TB
[15:08] <mdz> jono: documentation changes
[15:09] <mdz> Keybuk: FYI I've added an item to the agenda just now
[15:09] <Keybuk> jono: you took it as an action in the 2009-09-08 TB meeting
[15:09] <jono> Keybuk, oh, right, I was waiting on Keybuk to finish off a previous action to do this, I will look into it
[15:09] <jono> sorry about that
[15:09] <Keybuk> np, will carry over
[15:09] <jono> thanks
[15:09] <Keybuk> I'll remove the standing agenda item now in favour of tracking actions
[15:09] <Keybuk> [ACTION] jono to review and update governance documentation to reflect that the DMB is now handling developer applications, not the TB
[15:09] <MootBot> ACTION received:  jono to review and update governance documentation to reflect that the DMB is now handling developer applications, not the TB
[15:10] <Keybuk> [TOPIC] Units Policy
[15:10] <MootBot> New Topic:  Units Policy
[15:10] <Keybuk> I took an action for this at the last meeting, but noted I'd likely not have time
[15:10] <Keybuk> I was right, I didn't have time
[15:10] <jono> thanks Keybuk
[15:11] <Keybuk> since the release is next week, this seems ok to defer
[15:11] <kees> does anything remain other than a vote for the unit policy?
[15:11] <bdrung> maybe improve the wording
[15:12] <bdrung> are the any objection that should be discussed?
[15:12] <Keybuk> the exception also seemed ... odd
[15:12] <cjwatson> erk, sorry I'm late
[15:12] <Keybuk> e.g. "only the prefix is displayed and not the unit (e.g. M instead of MB)"
[15:13] <Keybuk> it seems much less difficult to simply state that traditional UNIX command-line tools are exempt, provided they provide options to select the output sizes
[15:13] <kees> (for the logs)  https://wiki.ubuntu.com/UnitsPolicy
[15:13] <Keybuk> [LINK] https://wiki.ubuntu.com/UnitsPolicy
[15:13] <MootBot> LINK received:  https://wiki.ubuntu.com/UnitsPolicy
[15:13] <Keybuk> I don't want to spend too much time on this today as we're all busy with release-related stuff
[15:13] <bdrung> Keybuk: yes, your idea is simpler. how about providing an exception list?
[15:14] <Keybuk> so let's continue this by e-mail
[15:14] <Keybuk> bdrung: right, that's what I was thinking
[15:14] <Keybuk> [ACTION] keybuk to drive units policy to completion and vote by e-mail
[15:14] <MootBot> ACTION received:  keybuk to drive units policy to completion and vote by e-mail
[15:14] <Keybuk> [TOPIC] EC2 image updates
[15:14] <MootBot> New Topic:  EC2 image updates
[15:14] <Keybuk> [LINK] https://lists.ubuntu.com/archives/ubuntu-devel/2009-September/028954.html
[15:14] <MootBot> LINK received:  https://lists.ubuntu.com/archives/ubuntu-devel/2009-September/028954.html
[15:15] <Keybuk> mdz: ?
[15:15] <smoser> this is my topic, but I am not exactly sure what is expected of me.
[15:16] <mdz> smoser sent an RFC to ubuntu-devel
[15:16] <smoser> the link above describes the proposal regarding support / updates to ec2 images.
[15:16] <mdz> the basic issue is that Ubuntu for EC2 is distributed as a pre-installed image
[15:16] <mdz> and the EC2 model is such that updates are not applied in the usual manner
[15:17] <mdz> (if they are, it needs to be done on every boot)
[15:17] <mdz> so he has proposed that we should periodically refresh the images to incorporate updates
[15:17] <kees> sounds reasonable.
[15:17] <Keybuk> ah, I wondered what he was proposing
[15:17] <mdz> he hasn't received any feedback on the proposal yet
[15:17] <cjwatson> that's the case for live CDs too, but I can see how UEC images are different since the usage model is different
[15:17] <Keybuk> he used lots of terms and abbreviations that only cloud people know ;)
[15:18] <smoser> (above, it is not on "every boot", but on every first boot of a new instance)
[15:18] <Keybuk> so it's entirely possible nobody outside of the UEC team knew what he was on about <g>
[15:18] <mdz> Keybuk: he did explain pretty clearly in the email, but it was long
[15:18] <Keybuk> mdz: I disagree
[15:18] <Keybuk> I read the entire e-mail
[15:18] <Keybuk> an I've just re-read it
[15:18] <Keybuk> and your one line explanation was far clearer
[15:19] <Keybuk> (remember, you know about cloud - I don't)
[15:19] <mdz> on EC2, the root filesystem and kernel are published separately, so it is possible to update the kernel while leaving the root filesystem alone, and vice versa
[15:19] <mdz> so he has proposed separate policies for when to update each
[15:19] <cjwatson> my main concern is release management; we know that point releases are a big whack of work, so this needs to be much more lightweight
[15:19] <kees> I would think a place like www.ubuntu.com/ec2-version-query/... would make a better official place to get AMI updates than on ~soren
[15:19] <mdz> when the kernel is updated, the rootfs would always be updated as well (since it contains the modules)
[15:20] <Keybuk> is the rootfs like a ramfs?
[15:20] <mdz> kees: smoser is in the process of replacing the (prototype) ~soren thing with something more official
[15:20] <Keybuk> or is the ramdisk something different?
[15:20] <mdz> Keybuk: it's typically a compressed writable filesystem
[15:20] <mdz> the ramdisk is the initrd
[15:20] <smoser> Keybuk, rootfs is a partition image (consumed by xen)
[15:20] <mdz> so there is kernel (AKI) and ramdisk (ARI)
[15:21] <Keybuk> what about the cases where you update the ramdisk and accidentally include updates to things like udev that aren't on the rootfs yet?
[15:21] <mdz> an AMI is a rootfs + a reference to an AKI and ARI used to boot it
[15:21] <mdz> smoser: have I got that right?
[15:21] <smoser> mdz, yes.
[15:21] <Keybuk> if you update the kernel, you need to update the initrd and root filesystem since they have modules on them
[15:21] <mdz> when an EC2 user wants to start a new Ubuntu system up, they just specify the AMI they want
[15:21] <Keybuk> if you update the root filesystem, you need to update the initrd too because it contains bits of it
[15:21] <kees> Keybuk: AIUI, you run the risk of hosing your image.
[15:22] <mdz> the AMI is a short, inscrutable hex number
[15:22] <Keybuk> if you update the initrd, you run the disk of including updates that aren't on the root filesystem yet
[15:22] <Keybuk> separate policies for them seems like a very bad idea
[15:22] <smoser> Keybuk, i will admit to not having thought of that.  However, the proposal is that a kernel update indicates a new root. so it should not be an issue.
[15:22] <sabdfl> are there items in the ramdisk which could trigger an update too? as i read it, it's only kernel updates that do so
[15:23] <kees> I think the point is that it's not just the kernel changing that should trigger an ARI/AMI update.
[15:23] <Keybuk> smoser: so when would you not just update all three bits at the same time?
[15:23] <Keybuk> as I see it, kernel implies initrd and rootfs update
[15:23] <smoser> any time the rootfs is updated it will take the most recent kernel/ramdisk at the time.
[15:23] <Keybuk> initrd means you must also update the rootfs otherwise you'll screw yourself one day
[15:24] <Keybuk> rootfs means you must also update the initrd
[15:24] <Keybuk> smoser: you can't do that
[15:24] <smoser> any time kernel/ramdisk is updated (in builds) it forces a refresh of root
[15:24] <Keybuk> if you update the rootfs, you must update the ramdisk too
[15:24] <mdz> a rootfs update does not generally require a kernel update, and may not require an initrd update
[15:24] <Keybuk> mdz: disagree strongly
[15:24] <mdz> Keybuk: generally, yes, but not always
[15:25] <mdz> Keybuk: an update to screen or w3m does not require a new initrd
[15:25] <cjwatson> can we determine this ad-hoc, based on (e.g.) the set of updates since the last image?
[15:25] <mdz> Keybuk: I don't necessarily disagree with you that we should update them in sync, as that would be simpler
[15:25] <Keybuk> mdz: and the cost of determining that for each release?
[15:25] <Keybuk> that starts to put a larger release management overhead for these
[15:25] <cjwatson> we can tell automatically whether a package calls update-initramfs in its postinst, plus perhaps a small number of exceptions
[15:25] <cjwatson> (e.g. busybox-initramfs, don't ask)
[15:26] <Keybuk> my between-the-lines reading was that you wanted light release management of "update the images this week"
[15:26] <Keybuk> is there a Bad Thing of just updating the three bits together
[15:26] <Keybuk> at least then you vastly reduce your testing matrix
[15:26] <mdz> we want a clear (preferably automatable) test to say "yes it is time to roll an update"
[15:26] <Keybuk> otherwise you really should be testing all combinations of kernel, initrd and rootfs
[15:26] <smoser> I apologize for being dense here, but I believe the proposal is to update the 3 bits together.
[15:27] <smoser> Keybuk, where do you see something that doesn't state that?
[15:27] <Keybuk> smoser: honestly, I can't understand half of your proposal
[15:27] <Keybuk> I don't know what an aki, ami, ari or uzi are ;)
[15:27] <smoser> Keybuk, fair enough.
[15:27] <mdz> Keybuk: I just explained
[15:28] <Keybuk> can we not just simply it to "UEC Image" ?
[15:28] <Keybuk> rather than resorting to jargon?
[15:28] <sabdfl> the proposal is mostly useful to people who do understand ubuntu and ec2. now that mdz's explained, scott, you could read it again and see if you're happy with it in the light of your newfound insight ;-)
[15:29] <mdz> Keybuk: sure
[15:29] <cjwatson> "At the time of publish, AMIs will be associated with the latest AKI/ARI
[15:29] <cjwatson> that is available."
[15:29] <cjwatson> I think Scott is requesting that we just bundle up a new AKI/ARI at the same time, too
[15:30] <Keybuk> sabdfl: I am doing so, and I think the proposal is still vastly overworded now I think I get it
[15:30] <cjwatson> or at least a new ARI (initrd), it's probably fairly easy to see when the AKI (kernel) doesn't need to change
[15:30] <Keybuk> cjwatson: right, I think that's what I mean
[15:30] <kees> IIUC, proposal is: if anything changes in kernel or ramdisk, AKI/ARI/AMI is generated.  otherwise, just AMI.
[15:31] <mdz> kees: that's my understanding as well
[15:31] <sabdfl> can we always detect that something needs to change in the rd?
[15:31] <kees> which means as long as there is a way to discover "current AMI", a user will always have the latest of everything published.
[15:32] <sabdfl> kees: no, i don't think the proposal is to roll a new set every time there is any update at all
[15:32] <mdz> kees: which is covered by the "Currency" section
[15:32] <sabdfl> just kernel updates, major security updates, and when the queue of updates is big
[15:32] <cjwatson> sabdfl: initrd change> yes (I think), but it may be more work than is worth it
[15:32] <smoser> if there is a reason to always update kernel/ramdisk with each new AMI, then I do not have a good reason why that should not occur.
[15:33] <Keybuk> smoser: I don't think you need to update the kernel bit (AKI?)
[15:33] <kees> sabdfl: right, I should restate it as: when something important changes in kernel or ramdisk, AKI/ARI/AMI is generated.  otherwise, just AMI.
[15:33] <Keybuk> if there's no new kernel, that's a static image
[15:33] <cjwatson> the initrd is tiny and quick to build by comparison with the rest
[15:33] <Keybuk> if you can auto-detect whether a new ARI is needed for a given AMI, then ok, otherwise I'd recommend always rolling a new ARI with a new AMI
[15:33] <Keybuk> (did I get that right? :p)
[15:33] <smoser> Keybuk, ah. ok. now i'm undertanding the problem.
[15:33] <cjwatson> Keybuk: my counter-proposal would be: when something important changes in kernel or ramdisk, AKI/ARI/AMI is generated.  otherwise, ARI and AMI
[15:34] <cjwatson> kees: ^-
[15:34] <Keybuk> cjwatson: isn't that what I just said? :p
[15:34] <cjwatson> Keybuk: sorry, I meant to direct that to kees
[15:34] <kees> cjwatson, Keybuk: yeah, good.
[15:34] <cjwatson> this is basically just defensive programming, since it's not trivial (not *that* hard, but) to tell when the initrd needs to change, and it's not that expensive to just change it anyway
[15:35] <Keybuk> cjwatson: agree
[15:35] <mdz> smoser: is there any cost related to releasing a new ARI which we might not be aware of?
[15:35] <smoser> not that i can think of.
[15:36] <Keybuk> . o O { why do UEC images have ramdisks anyway, surely the kernel can just mount the rootfs? }
[15:36] <smoser> only that I had previously assumed kernel:ramdisk was 1:1, not 1:N
[15:36] <mdz> ok, in that case I think I more or less agree with cjwatson, except s/ or ramdisk/
[15:36] <mdz> i.e.: if the kernel changes, roll a new AKI/ARI/AMI, otherwise, roll new ARI/AMI with the old AKI
[15:36] <Keybuk> mdz: right, good catch
[15:37] <Keybuk> ARI changes means ARI/AMI not AKI/ARI/AMI
[15:37] <kees> Keybuk: I thought you had concerns about ramdisky things like udev?
[15:37] <cjwatson> mdz: yes
[15:37] <mdz> Keybuk: good question
[15:37] <mdz> smoser: is it possible to omit the ramdisk, technically?
[15:38] <Keybuk> kees: ramdisky things like udev would be fine in that situation - my concern is the udev version in the ramdisk and rootfs being out of sync with each other
[15:38] <smoser> from a 'allowed by amazon' perspective, yes
[15:38] <Keybuk> kees: since they transfer data by a secret protocol known to no man that changes with the winds ;)
[15:38] <smoser> i'm not sure as to whether or not our kernels have all the needed drivers built in. but obviously they could.
[15:39] <mdz> obviously that's not an option for 9.10
[15:39] <smoser> right.
[15:39] <mdz> or older releases
[15:39] <mdz> so we need to address the ramdisk question anyway
[15:39] <kees> Keybuk: ok
[15:39] <mdz> and can look at whether it can be eliminated in lucid
[15:39] <Keybuk> so, new AKI -> new AKI/ARI/AMI
[15:39] <Keybuk> new ARI or AMI -> new ARI/AMI
[15:39] <Keybuk> ?
[15:40] <mdz> smoser: do we presently provide any mechanism by which updates can be automatically installed at boot time?
[15:40] <smoser> via user-data.
[15:40] <mdz> or is that something that users have to roll their own?
[15:40] <smoser> ie, if user boots with '--user-data "#!/bin/sh\napt-get update && apt-get dist-upgrade"'
[15:40] <mdz> smoser: ok, so they can pass in a script which does it, but we don't provide a simple toggle or anything
[15:40] <smoser> that will get done.
[15:40] <smoser> mdz, correct, we do not.
[15:41] <smoser> there is not at the moment a general "config" like format to feed to an instance, only scripts.
[15:42] <mdz> smoser: ok, so for 9.10 purposes, users are on their own with regard to keeping up to date
[15:42] <smoser> correct.
[15:42] <mdz> in that case, does it make sense to measure the size of updates or time to install?
[15:42] <mdz> should we rather just update it every N days or whenever there's a critical issue?
[15:42] <mdz> (for 9.10)
[15:43] <mdz> kees: have you considered how this would tie into the security team's process?  presumably the USN should mention the new AMI where appropriate
[15:43] <smoser> I do not have the experience with SRU that others here have. but it seems that updating every N days when there are zero (or very few) updates is overkill.
[15:44] <kees> mdz: we have been pushing for ec2 to have a way for people to "get the latest".  I don't want to delay kernel publications on an update of AKI.
[15:44] <mdz> smoser: my point was, if that criterion is based on the assumption that everyone will install updates at boot, is that a valid assumption given that it relies on the user to implement it manually?
[15:44] <mdz> kees: what if the security team could push a new AKI?
[15:45] <smoser> that is a valid question.  I have had the feeling from others that it is fairly common to do update on first (or every) boot
[15:45] <mdz> smoser: which is an EC2 question rather than SRU
[15:45] <mdz> smoser: ok
[15:45] <kees> mdz: I would rather got gain that responsibility as it sets a bad precedence.  we are basically "upstream" for all derivatives.
[15:46] <mdz> smoser: we certainly shouldn't do an update if there are no updates to packages in the image
[15:46] <smoser> realize that the image as it is is basically useless, so each instance that is created will have *something* done to it to make it useful to the user
[15:46] <sabdfl> could we move all the kernel bits from the rootfs into the rd?
[15:46] <smoser> likely they realize that one of the things they should do is update
[15:46] <mdz> smoser: right, and we are assuming that a standard part of everyone's user-data script (who cares about security) is to install updates
[15:46] <smoser> correct
[15:46] <mdz> which seems reasonable at this stage, though in the future I think we should explore simplifying that
[15:47] <mdz> e.g. have unattended-upgrades automatically run at boot on EC2?
[15:47] <mdz> something to think about for the future
[15:48] <smoser> yes. i think that it is reasonable to have that as a default that can be easily turned off
[15:48]  * kees agrees strongly
[15:48] <mdz> smoser: it sounds like there is general agreement that 1) it is appropriate to issue new images periodically, 2) when to update AKI vs. ARI vs. AMI
[15:49] <mdz> does anyone have concerns with smoser's proposal to refresh based on time-to-install-updates or an approximation thereof?
[15:49] <sabdfl> fine by me
[15:49] <Keybuk> seems ok
[15:50] <mdz> how about the support lifetime section, which basically says we will continue to provide updated images for the maintenance lifetime of the product?
[15:50] <kees> it was time-to-install or security update criticality  (AMI Updates / Stable Releases / a & b)
[15:50] <mdz> for 8.04 LTS and 9.10+
[15:50] <Keybuk> that seems logical
[15:50] <sabdfl> +1
[15:50] <mdz> kees: yes, thanks for the correction
[15:50]  * kees now
[15:50] <kees> er
[15:50] <Keybuk> we support an Ubuntu install with some updates installed for the same time period
[15:50]  * kees nods
[15:51] <Keybuk> philosophically speaking, these images are just an alternate way of providing the same updates
[15:51] <mdz> so I think that leaves only 1) how users will find out about, and start using, the new AMIs (Currency)
[15:51] <mdz> are there any other outstanding questions or concerns?
[15:52] <mdz> I agree with Keybuk that it would help if the document were condensed
[15:52] <mdz> now that we have consensus, it should probably be made more procedural, i.e. step-by-step decision-making and release process, rather than explanation/RFC
[15:54] <smoser> I will update the wiki document.
[15:54] <Keybuk> ok
[15:54] <Keybuk> anything else on this topic?
[15:54] <mdz> if there are no other questions, I suggest that the next steps should be: 1. smoser to redraft, and 2. continue working on a system to allow users to find the right AMI
[15:55] <kees> sounds right
[15:55] <Keybuk> ok
[15:55] <Keybuk> [TOPIC] Community Bugs
[15:55] <MootBot> New Topic:  Community Bugs
[15:55] <Keybuk> [LINK] https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
[15:56] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
[15:56] <Keybuk> none
[15:56] <mdz> smoser: thanks
[15:56] <Keybuk> [TOPIC] # Select a chair for the next meeting
[15:56] <MootBot> New Topic:  # Select a chair for the next meeting
[15:56] <Keybuk> by my reckoning, it's mdz's turn next ;)
[15:56] <Keybuk> though it's posibble that there's a lot of leave being taken that week
[15:56] <kees> cjwatson: anything to cover for "Archive reorganisation" ?
[15:56] <mdz> I will be traveling and may or may not be able to attend the meeting
[15:56] <cjwatson> kees: not right now
[15:57] <kees> cjwatson: ok, thanks
[15:57] <pitti> vote is still going on
[15:57] <mdz> I will try to make it, but I don't think I can commit to chair
[15:57] <cjwatson> I will be travelling week after next as well
[15:57] <Keybuk> I am away that week
[15:57] <kees> I can chair it, but it sounds like we'll lack quorum?
[15:57] <mdz> pitti, kees, sabdfl?
[15:58] <sabdfl> vote?
[15:58] <pitti> I should be available
[15:58] <sabdfl> ah, attendance
[15:58] <sabdfl> i'll be there
[15:58] <mdz> sabdfl: chair
[15:58] <sabdfl> mdz: i thought scott said it was your turn
[15:58] <Keybuk> sabdfl: mdz is away that week
[15:58] <kees> 4 is quorum?
[15:59] <Keybuk> or possibly won't be able to make it
[15:59] <Keybuk> sabdfl: and technically speaking, it's your turn since you've never chaired :p
[15:59] <sabdfl> i'm just a lowly ex officio member here, iirc
[16:00] <sabdfl> ok, i'll chair it
[16:00]  * bdale chuckles
[16:00] <mdz> Keybuk: AOB?
[16:01] <Keybuk> [TOPIC] AOB
[16:01] <MootBot> New Topic:  AOB
[16:01] <Keybuk> none, good
[16:01] <Keybuk> #endmeeting
[16:01] <MootBot> Meeting finished at 10:01.
[16:01] <sabdfl> thanks all
[16:01] <Keybuk> thanks everyone
[16:01] <pitti> thanks all
[16:02]  * mathiaz waves
[16:02] <ttx> o/
[16:02] <Daviey> \o
[16:02] <soren> o/
[16:02] <zul> heylo
[16:03] <ttx> kirkland, smoser: around ?
[16:03] <smoser> here
[16:03] <sommer> o//
[16:04] <ttx> waiting for mdz...
[16:05] <mdz> ttx: here
[16:05] <mdz> #startmeeting
[16:05] <kirkland> o/
[16:05] <MootBot> Meeting started at 10:05. The chair is mdz.
[16:05] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:06] <mdz> [LINK] https://wiki.ubuntu.com/ServerTeam/Meeting
[16:06] <MootBot> LINK received:  https://wiki.ubuntu.com/ServerTeam/Meeting
[16:06] <mdz> [topic] Review ACTION points from previous meeting
[16:06] <MootBot> New Topic:  Review ACTION points from previous meeting
[16:06] <mdz> ACTION: kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt
[16:06] <kirkland> mdz: not yet
[16:06] <mdz> [action]  kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt
[16:06] <kirkland> mdz: i plan on doing some documentation this week
[16:06] <MootBot> ACTION received:   kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt
[16:06] <mdz> ACTION: zul to fix m2crypto test suite and ensure that MIR is processed
[16:07] <mdz> zul: ?
[16:07] <zul> testsuite deferred to lucid but its in main now
[16:07] <mdz> zul: is there a bug open to make sure we revisit the test suite for lucid?
[16:07] <zul> mdz: yes
[16:08] <mdz> zul:  let me know what the bug number is when you can pull it up
[16:08] <mdz> ACTION: mathiaz to add test case for image store in testcases wiki
[16:08] <mathiaz> mdz: not done yet.
[16:08] <mdz> [action] mathiaz to add test case for image store in testcases wiki
[16:08] <MootBot> ACTION received:  mathiaz to add test case for image store in testcases wiki
[16:08] <mdz> [topic] Karmic RC (ttx)
[16:08] <MootBot> New Topic:  Karmic RC (ttx)
[16:09] <ttx> ACTION: zul to add missing server-ship packages to ubuntu-server
[16:09] <ttx> you missed that one ^
[16:09] <zul> mdz: oh kees fixed it #451998
[16:09] <zul> ttx/mdz: thats done as well
[16:09] <mdz> ttx: oh, thanks
[16:10] <ttx> I wanted us to revisit the list of bugs targeted to release and current targets of opportunity (karmic-nominated bugs)
[16:10] <mdz> ttx: urls?
[16:10] <ttx> I pulled up a list at https://wiki.ubuntu.com/ServerTeam/ReleaseStatus
[16:10] <ttx> since some of them are of interest to us but not assigned to a team member
[16:11] <mdz> bug 452665 is fixed, I believe
[16:11] <mdz> oh, they are listed as fixed ,NM
[16:11] <ttx> so jdstrand added a release-targeted bug, bug 455832
[16:11] <mdz> I had not seen 455832 before
[16:11] <ttx> its quite recent
[16:11] <mdz> ah, just filed 17  hours ago
[16:12] <ttx> also not assigned to anyone -- I was considering removing the milestone and keeping int as a target of opportunity
[16:12] <ttx> unless someone says its a release blocker
[16:12] <mdz> kirkland: is this related to bug 432154 or bug 419590?
[16:12] <kirkland> ttx: i can attempt to reproduce that, and look at it, if it's release critical
[16:12] <mdz> it is not marked as a regression
[16:12] <kirkland> mdz: possibly; the consensus from upstream was that dynamic block storage attach/detach are not heavily used or tested
[16:13] <jdstrand> the attach/detach work
[16:13] <kirkland> mdz: given eucalyptus' dependency on that, it might be worth us investing some time/effort testing and developing this upstream
[16:13] <mdz> jdstrand: is it a regression?
[16:13] <jdstrand> that is what I was testing, and I accidentally attached a device two times in a row with the same target dev
[16:13] <jdstrand> and it segfaulted
[16:13] <jdstrand> I did not test on jaunty, but I can
[16:13] <smoser> it is not a regression from jaunty
[16:14] <mdz> ok, in that case I would not  consider it critical for karmic
[16:14] <ttx> if its avoidable in normal use, I would not keep it as a RC bug
[16:14] <smoser> it was at best random success there.
[16:14] <mdz> it likely doesn't affect eucalyptus
[16:14] <mdz> and it doesn't sound like a "normal" use case
[16:14] <jdstrand> I can say that anyone in the libvirtd group, or with qemu+ssh//<host>/system access can DoS libvirtd with this
[16:14] <ttx> mdz: should we still keep it as a karmic-nominated bug ?
[16:15] <mdz> ttx: smoser and I discussed bug 451881. since it only affects UEC, and not EC2, it is not critical for karmic (though he will continue to investigate)
[16:15] <ttx> i.e. moving it to the next list ?
[16:15] <jdstrand> if a user or application misbehaves libvirtd goes down
[16:15] <mdz> ttx: no, I suggest we wontfix it for karmic
[16:15] <ttx> the "Other targeted bugs" should onnly contain bugs that we may want to fix before release
[16:16] <ttx> mdz ok
[16:16] <mdz> soren: how serious is bug 410886?
[16:16] <mdz> it's marked High and assigned to cjwatson
[16:16] <soren> mdz: Not at all anymore.
[16:16] <ttx> 455832 and 451881 > wontfix for karmic
[16:17] <mdz> in fact he closed it in a grub2 upload
[16:17] <mdz> grub2 (1.97~beta3-1ubuntu8) karmic; urgency=low
[16:17] <mdz>   [ Colin Watson ]
[16:17] <mdz>   * debian/control: Conflict with grub (<< 0.97-54) as well as grub-legacy
[16:17] <mdz>     (see LP #410886).
[16:17] <mdz> soren: can it be closed, or is there still an issue here?
[16:17] <cjwatson> no, that didn't close 410886
[16:17] <mdz> cjwatson: ah, I see
[16:17] <soren> mdz: There's still an issue, but it's not critical anymore.
[16:17] <cjwatson> the vmbuilder package needs to have the patch from trunk merged into it, does it not?
[16:17] <cjwatson> did that happen?
[16:17] <soren> I thought it did. I can check up on it.
[16:18] <cjwatson> the patch> to make it use grub from the chroot rather than the host
[16:18] <soren> Right.
[16:18] <cjwatson> I saw a comment in the last few days suggesting it hadn't been
[16:18] <soren> Ah.
[16:18]  * soren adds to TODO
[16:18] <mdz> soren: TODO->post-karmic?
[16:18] <mdz> i.e. we can untarget this bug?
[16:18] <cjwatson> it should be pre-karmic
[16:18] <mdz> ack
[16:18] <soren> Pre-karmic.
[16:18] <mdz> milestoned and assigned to soren
[16:18] <cjwatson> assuming it's what I think it is, vm-builder only works if you have grub (1) installed in the host
[16:19] <mdz> bug 362511: OpenSSH force-command unable to pass arguments along to internal-sftp (cjwatson)
[16:19] <cjwatson> I'd entirely forgotten about that bug, TBH; I don't think it's likely to happen for karmic, unless somebody thinks it's urgent enough to steal it
[16:19] <mdz> cjwatson: given this is marked Low, I'm assuming it's post-karmic now
[16:19] <mdz> the next two eucalyptus bugs ttx and I already discussed
[16:19] <ttx> ok, wontfixed for karmic
[16:19] <mdz> next is bug 455411
[16:20] <mdz> kirkland: given that's Low, I'm assuming it's missed the cut now?
[16:20] <kirkland> mdz: ttx filed it, thought it was low, i didn't get to it yesterday
[16:20] <ttx> mdz: its low because its harmless to load the kvm module twice
[16:21] <mdz> ttx: wontfix for karmic then
[16:21] <ttx> ok
[16:21] <mdz> (waiting for LP)
[16:21] <ttx> mdz: i'll do it
[16:21] <mdz> bug 453495 is next
[16:21] <ttx> taht's another recent one filed by jdstrabd
[16:21] <ttx> jdstrand, even
[16:22] <kirkland> those other arches are in qemu-kvm-extras, in universe; very low priority, IMHO
[16:22] <mdz> jdstrand: I don't understand the problem from your description
[16:22] <mdz> oh, it's not selecting arm
[16:22] <jdstrand> mdz: if you use kvm, you can specify the arch, i686 or x86_64
[16:22] <mdz> right
[16:23] <mdz> agreed, this doesn't sound High and we can deal with it post-Karmic
[16:23] <jdstrand> mdz: when using qemu, you can specify the others in virt-manager, but the resulting VM is x86_64
[16:23] <mdz> bug 453453 is another jdstrand libvirt bug
[16:23] <jdstrand> (I put it high for virt-manager, but realize it is universe)
[16:23] <mdz> jdstrand: right, I understand now, thanks
[16:24] <ttx> mdz: 453495 wontfix for karmic
[16:24] <mdz> jdstrand: given it doesn't affect primary functionality (only functionality used with a universe package), I think we should consider it lower importance
[16:24] <jdstrand> sure. I am not suggesting it take priority over other items
[16:24] <mdz> jdstrand: you marked this a regression; when did it last work?
[16:25] <jdstrand> mdz: I am almost sure it worked in jaunty, but I didn't test it recently
[16:25] <jdstrand> (we are still talking about 453495, right?)
[16:25] <jdstrand> mdz: I can retest it
[16:25] <jdstrand> (on jaunty(
[16:25] <jdstrand> )
[16:25] <mdz> jdstrand: (yes)
[16:26] <mdz> but now we need to talk about 453453
[16:26] <kirkland> sounds support has come and gone, come and gone in karmic
[16:26] <mdz> this is Medium, which I agree with; not sure why it's targeted to Karmic though
[16:26] <mdz> oh, because it's a regression
[16:26] <mdz> jdstrand: er, yes, my last question was about 453453, not 453495
[16:26] <kirkland> i have verified that sound works when running kvm from the command line
[16:26] <kirkland> but not when through libvirt
[16:27] <jdstrand> actually, I see it work in libvirt too
[16:27] <mdz> kirkland: when run through libvirt, does sound just not work, or does it make the VM unusable?
[16:27] <jdstrand> I think it is highly dependent on what is going on in the host as to whether or not it hangs the guest when initializing the sound device or if there is sound at all in the guest
[16:27] <kirkland> mdz: i saw the hang jdstrand mentions for the first time on Friday
[16:27] <kirkland> mdz: it's a race or something; non-deterministic failure
[16:28] <jdstrand> I agree with kirkland's assessment
[16:28]  * kirkland borrowed jdstrand's assessment, probably :-)
[16:28] <mdz> kirkland: if it's come and gone, was there an earlier bug report about it?
[16:28] <jdstrand> probably why it sounded *so right* ;)
[16:29] <kirkland> mdz: no
[16:29] <mdz> at this point it doesn't seem realistic to do anything about this bug for 9.10, though we could consider it for SRU
[16:29] <mdz> kirkland: your call; please either milestone for karmic-updates or wontfix for karmic
[16:29] <mdz> need to keep moving
[16:29] <mdz> bug 453467
[16:29] <kirkland> mdz: sound issues in VM's are *extremely* low priority, for me
[16:30] <mdz> this is Low
[16:30] <mdz> this seems related to the other bug, selecting an architecture
[16:30] <mdz> doesn't seem 9.10-critical to me
[16:31] <mdz> bug 407949
[16:31] <ttx> mdz: agreed, wontfixing for karmic as well
[16:31] <jdstrand> mdz: that may be true, but I think it is more a gui failure in virt-manager, though I haven't looked at it too closely
[16:31] <mdz> smoser?
[16:32] <smoser> i just pushed  a branch with a suggested fix.
[16:32] <smoser> its very trivial, just catch the error and fall back.
[16:32] <smoser> rather than not catching error and failing with python trace
[16:32] <mdz> smoser: does it cause the UEC images to fail to initialize correctly?
[16:32] <ttx> smoser: that would involve a UEC/EC2 image respin, but not an ISO respin, right
[16:33] <mdz> ttx: correct
[16:33] <smoser> it does cause UEC images to fail to initialize correctly.  They do not get locale set.
[16:33] <smoser> i believe that they still have a functional /etc/apt/sources.list though.
[16:34] <mdz> smoser: ok, milestoned for 9.10
[16:34]  * Daviey noticed user-data not working as expected yesterday in ec2.
[16:34] <ttx> I propose we skip the UEC/EC2 release process discussion and do it after meeting with smoser
[16:34] <ttx> mdz: Test coverage ?
[16:34] <mdz> ttx: yes, I emailed you with some notes about this
[16:35] <soren> "Test coverage"?
[16:35] <mdz> ISO testing
[16:35] <soren> Ah.
[16:35] <ttx> Some server-related tests in the ISO tracker are not covered by a team member
[16:35] <mdz> the list of deliverables which need testing is at http://iso.qa.ubuntu.com/qatracker/build/ubuntuserver/all
[16:35] <mdz> don't worry about ARM for the moment
[16:36] <mdz> the main gaps are:
[16:36] <mdz> 1. netboot
[16:36] <mdz> 2. upgrades
[16:36] <mdz> who has a setup where they can test netboot installations?
[16:36] <mdz> this is fastest with a local mirror, but can be done over the Internet as well with a netboot setup
[16:37] <Daviey> mdz: \o
[16:37] <kirkland> mdz: o/
[16:37] <mdz> Daviey: kirkland: thanks for stepping up
[16:37] <ttx> I can do upgrade testing, though the test contents are undefined right now
[16:37] <davmor2> mdz: I'm just finishing the netboot's
[16:37] <mdz> upgrade testing is fairly straightforward and can be done in a VM
[16:37] <mdz> ttx: yes, we need to get a test case written
[16:37] <zul> ill do that one
[16:38] <davmor2> mdz: at least for i386 and amd 64
[16:38] <mdz> zul: can you write up a test case which is equivalent to the desktop one, but for a server install?
[16:38] <zul> mdz: sure
[16:38] <mdz> davmor2: great
[16:38] <mdz> [action] zul to write up server upgrade test case
[16:38] <MootBot> ACTION received:  zul to write up server upgrade test case
[16:38] <mdz> ttx: ok to move on?
[16:38] <ttx> yep
[16:39] <mdz> [topic] Review progress made on the Roadmap:
[16:39] <MootBot> New Topic:  Review progress made on the Roadmap:
[16:39] <mdz> [topic] eucalyptus status
[16:39] <MootBot> New Topic:  eucalyptus status
[16:39] <ttx> I have a few eucalyptus bugs I wanted to bring up
[16:39] <mdz> kirkland, ttx?
[16:39] <kirkland> mdz: well, we've continued to improve
[16:39] <ttx> current status is: we might still try to fix bug 455816 but its unlikely
[16:40] <ttx> and we would fix bug 453456 if log rotation isn't functional
[16:40] <mdz> ttx: 453456->can be fixed in SRU
[16:40] <ttx> we would fix bug 455293 only if something else gets fixed
[16:40] <mathiaz> ttx: I plan to test cjwatson branch for bug 455816 today
[16:40] <kirkland> mdz: i think we fixed ~36 bugs in 9 uploads last week
[16:41] <mdz> yes, there was a lot of great work done last week while I was away
[16:41] <ttx> I'm slightly worried by bug 455625, if its confirmed
[16:41] <ttx> and also note that I hit systematically bug 452556 and bug 444352 in my ISO testing
[16:41] <ttx> which means we might need to release-note them
[16:42] <ttx> especially if other testers hit those as well.
[16:42] <nurmi> ttx: We're going to be looking into 455625 asap
[16:42] <ttx> nurmi: it's a little... long to reproduce
[16:42] <nurmi> ttx: 452556 is confirmed, we're working on a fix
[16:42] <mdz> nurmi: thanks, that would be a great help
[16:42] <jsalisbury> ttx: I am going to try reducing the lease time to try and reproduce quicker
[16:43] <ttx> nurmi: also please comment on bug 453456 with a pointer on where the log rotation is implemented in code
[16:43] <mdz> ttx: is 452556 9.10 critical?
[16:43] <mathiaz> nurmi: IIUC guests don't know about their public IPs?
[16:43] <ttx> mdz: no. It's quite easy to workaround
[16:43] <nurmi> jaslisbury: the public addresses are not handed out by DHCP
[16:43] <nurmi> mathiaz: that is correct
[16:43] <mathiaz> nurmi: right - that's what I though
[16:43] <mdz> [action] nurmi to investigate bug 455625
[16:43] <MootBot> ACTION received:  nurmi to investigate bug 455625
[16:43] <ttx> mdz: but could be release note material if systematic
[16:44] <ttx> that's all from me on Eucalyptus
[16:44] <kirkland> nurmi: mdz: I think we're going to need to author some comprehensive documentation on the ip address handling in UEC
[16:44] <mdz> ttx: agreed, please open an ubuntu-release-notes task on it
[16:44] <kirkland> it's complex
[16:44] <mdz> kirkland: ok, I see you have documentation on the agenda later
[16:44] <mdz> ttx: can we move on from eucalyptus?
[16:44] <ttx> yes
[16:44] <mdz> [topic] UEC images (smoser)
[16:44] <MootBot> New Topic:  UEC images (smoser)
[16:45] <mdz> I looked at this with smoser yesterday, and we looked to be in good shape
[16:45] <mdz> [link] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=uec-images
[16:45] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/+bugs?field.tag=uec-images
[16:45] <smoser> only issue open is the locale on UEC
[16:45] <smoser> s/open/known and to-be-fixed/
[16:45] <mdz> which we already discussed
[16:45] <mdz> [topic] EC2 images (smoser)
[16:45] <MootBot> New Topic:  EC2 images (smoser)
[16:45] <mdz> [link] https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=ec2-images
[16:45] <MootBot> LINK received:  https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=ec2-images
[16:46] <mdz> also reviewed yesterday, also judged OK for 9.10
[16:46] <mdz> smoser: any changes?
[16:46] <smoser> no.
[16:46] <mdz> lovely
[16:46] <mdz> [topic] Reference UEC appliance (soren)
[16:46] <MootBot> New Topic:  Reference UEC appliance (soren)
[16:47] <mdz> soren: I tried to get some help on this while we were on holiday last week, but it got dropped, so there hasn't been progress since you left
[16:47] <mdz> soren: what remains to be done on getting a demo appliance ready to ship?
[16:48] <mdz> soren: hello?
[16:48] <mdz> ttx: do you know soren's status on this?
[16:48] <ttx> mdz: no. he is working on it though, has asked questions about EBS support
[16:48] <kirkland> mdz: i asked him about it this morning; he said it's "on track" for release
[16:49] <kirkland> mdz: he said there wasn't progress besides what he's posted on ubuntu-devel@
[16:49] <mdz> ttx: the "demo" shouldn't require EBS; we should get the demo completed and then work on a persistent one
[16:49] <soren> Sorry, my wifi dropped for a minute.
[16:50] <soren> The demo will very closely resemble what I posted the week before last.
[16:50] <soren> I'm getting the build of it cleaned up, but I'm having a weird problem with mysql.
[16:50] <mdz> soren: can it be ready by Thursday?
[16:50] <soren> I'm working on it.
[16:50] <soren> The completely unpersistent one, yes.
[16:50] <mdz> ok
[16:50] <ttx> on the appliance store side, who tested that ?
[16:51] <mdz> [action] soren to complete demo virtual appliance
[16:51] <MootBot> ACTION received:  soren to complete demo virtual appliance
[16:51] <mdz> [topic] UEC appliance store (niemeyer)
[16:51] <MootBot> New Topic:  UEC appliance store (niemeyer)
[16:51] <mdz> Gustavo is on leave I think
[16:51] <kirkland> ttx: mathiaz tested the appliance store when he was here in Austin
[16:51] <ttx> mathiaz: did you test it since it was fixed ?
[16:51] <mdz> kirkland: mathiaz tested the eucalyptus interaction with the "fake" test store
[16:51] <mdz> I'm not sure if it has been validated against the production store yet
[16:51] <nurmi> ttx: I tested a bit shortly after austin, with the fake store as well
[16:51] <kirkland> mdz: right, sorry
[16:51] <mdz> someone needs to do that ASAP
[16:51] <mathiaz> mdz: nope - not validated against the production server
[16:52] <mathiaz> gustavo is on vacation today - so I don't know what's the state of the server side
[16:52] <ttx> is that production server up already ?
[16:52] <mdz> ttx: so I've heard
[16:52] <mathiaz> and a appliance is actually needed to do the complete testing
[16:52] <mdz> [action] mdz to chase down details on production image store
[16:52] <MootBot> ACTION received:  mdz to chase down details on production image store
[16:52] <mdz> [action] mathiaz to test UEC integration with production image store
[16:52] <MootBot> ACTION received:  mathiaz to test UEC integration with production image store
[16:52] <soren> The standard UEC image should be the first appliance, shouldn't it?
[16:53] <mdz> soren: we can use a "blank" 9.10 appliance as well, for test purposes
[16:53] <soren> I mean... that's clearly the most obvious way to publish that.
[16:53] <mathiaz> soren: I'd thought so
[16:53] <mdz> mathiaz: so we shouldn't need to block on soren
[16:53] <mathiaz> mdz: agreed.
[16:53] <mdz> the stock 9.10 UEC image should be able to go in the store
[16:53] <mdz> [topic] UEC documentation (kirkland)
[16:53] <MootBot> New Topic:  UEC documentation (kirkland)
[16:53] <mdz>     *
[16:53] <mdz>       What needs to be documented, where, and by whom? How can you help? (DustinKirkland)
[16:53] <kirkland> > [1] http://help.ubuntu.com/community/UEC
[16:53] <kirkland> > [2] http://help.ubuntu.com/community/UEC/PackageInstall
[16:53] <kirkland> those are two links to documentation
[16:53] <ttx> [1] is in reasonably good shape
[16:54] <kirkland> we also have testcases in the iso testing wiki
[16:54] <ttx> [2] needs a lot of work
[16:54] <kirkland> these materials need to converge on something we can point UEC users to
[16:54] <kirkland> i'm willing and able to help whip those into shape
[16:54] <ttx> I recently removed the "wrong" instructions from [2] (bundle your running kernel with UEC images)
[16:54] <nurmi> kirkland: i can help as well
[16:54] <kirkland> but I'm proposing that there are more people here that can help enhance that
[16:54]  * kirkland high fives nurmi
[16:54] <mdz> thanks, nurmi
[16:54] <kirkland> anyone else?
[16:55] <kirkland> ttx?  mathiaz?
[16:55] <ttx> kirkland: count me in
[16:55] <kirkland> shall we split the responsibilities?
[16:55] <mdz> kirkland: what kind of help is needed? I'm sure there are plenty of people who can read and edit for clarity, but fewer who can actually run through an end-to-end test
[16:55] <mathiaz> kirkland: I can review the PackageInstall doc
[16:55] <ttx> though I don't have the necessary hw to tset multicomponent, I can test the "by package" install
[16:55] <kirkland> or just let it grow organically?
[16:55] <mathiaz> kirkland: as this is what I'm mostly doing in my installs
[16:56] <kirkland> mdz: i've been driving my installs from the testcases wiki ... i was thinking of shifting to drive my installs from the documentation
[16:56] <ttx> I think [2] should be split between two scenarios, multicomponent and multicluster
[16:56] <kirkland> mdz: once we all started working from the test cases wiki, it really improved dramatically
[16:56] <kirkland> i think something along these lines will help
[16:57] <kirkland> but with more focus on explanation
[16:57] <kirkland> rather than copy-n-paste commands
[16:57] <mdz> kirkland: it would make sense to have one set of setup instructions, and just reference that
[16:57]  * mathiaz thinks testcases and documentation should be merged at some point in the future
[16:57] <kirkland> mdz: of course
[16:57] <ttx> mathiaz: the testcase is script-oriented, the doc is human-readability-oriented
[16:58] <kirkland> okay, so we first agree on a format
[16:58] <mathiaz> ttx: I have an idea about that - but right now is not the time to discuss it ;)
[16:58] <ttx> I tried to avoid obscure script combos in [1]
[16:58] <ttx> yes, lets take this off-meeting
[16:58] <mdz> ok, we are almost out of time, can we close on documentation?
[16:58] <kirkland> mdz: yes, i think we have some volunteers now
[16:58] <mdz> there is one to-be-assigned bug: bug 455873
[16:58] <ttx> kirkland, mathiaz: email, ubuntu-cloud or ubuntu-server ML ?
[16:58] <mdz> bug 455873
[16:58] <kirkland> ttx: ubuntu-server, i suggest
[16:59]  * mathiaz agrees
[16:59] <ttx> kirkland: you start it, you choose
[16:59] <kirkland> ttx: okay
[16:59] <ttx> mdz: I think zul proposed to take it
[16:59] <mdz> it's "mod_proxy causes duplicate query strings when nocanon option is used"
[16:59] <ttx> if that's the one I think it is
[16:59] <zul> yeah I did
[16:59] <mdz> on apache2
[16:59] <mdz> ok, assigned
[16:59] <mdz> I assume it is not 9.10-critical
[17:00] <zul> its for hardy
[17:00] <mathiaz> mdz: nope - fixed in karmic
[17:00] <ttx> zul: prio 2
[17:00] <zul> k
[17:00] <mdz> please update the bug to reflect that it's 8.04
[17:00] <ScottK> Just to toss in a clamav update: clamav 0.95.3 will likely be released on Monday, so it'll go to -proposed.  i hope to have some post-RC packaging fixes though.
[17:00] <mdz> mathiaz: can we skip the SRU review?
[17:00] <mathiaz> mdz: sure
[17:00] <mdz> [topic] AOB
[17:00] <MootBot> New Topic:  AOB
[17:01] <mdz> ScottK: ok, thanks
[17:01] <mdz> anything else?
[17:01] <zul> nope
[17:01] <mdz> ok, looks like we are in pretty good shape overall. thanks, all
[17:01] <mdz> #endmeeting
[17:01] <MootBot> Meeting finished at 11:01.
[17:25] <jcastro> nurmi: ping!
[17:26] <jcastro> nurmi: I need a response to my mail wrt UDS
[18:16] <nurmi> jcastro: sent via email, apologies for the delay
[18:17] <jcastro> nurmi: no worries