[08:31] <ApOgEE-> hi elkbuntu
[08:32] <ApOgEE-> hi persia
[08:35] <ApOgEE-> hi all
[08:45] <Hobbsee> ApOgEE-: hi, but could you use #ubuntu-offtopic for general chatting?  This channel is only to be used for meetings.  Thanks!
[08:52] <ApOgEE-> Hobbsee, ok
[16:42] <paddax> hi
[18:00] <pedro_> hello!
[18:00] <heno> hey!
[18:00] <davmor2> Yay with have Ubottu :)
[18:00]  * cgregan waves
[18:00] <bdmurray> hi
[18:00] <davmor2> Hello everybody :)
[18:00]  * ogasawara waves
[18:01] <sbeattie> Hello!
[18:01] <heno> sbeattie, did you get some sleep? :)
[18:01] <heno> late night testing I saw
[18:02] <davmor2> only in between testing :)
[18:02] <heno> #startmeeting
[18:02] <MootBot> Meeting started at 12:03. The chair is heno.
[18:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:02] <sbeattie> Yeah, I got a little, helping to get the kids ready this morning hurt a litle.
[18:02] <heno> \o/
[18:02] <pedro_> yay for the bot
[18:03] <heno> [TOPIC]: Outstanding items from last meeting
[18:03] <MootBot> New Topic: : Outstanding items from last meeting
[18:03] <davmor2> should it be S instead of s?
[18:03] <davmor2> no
[18:03] <heno> I believe cgregan was to look at LP team structures for qa
[18:03] <cgregan> Yes
[18:04] <heno> but in the meantime LaserJock has set up a team :)
[18:04] <cgregan> hehe
[18:04] <cgregan> I can review
[18:04] <cgregan> What is the URL?
[18:04] <heno> cgregan: perhaps you can just look at what was set up?
[18:04] <heno> right
[18:05] <pedro_> http://launchpad.net/~ubuntu-qa <-
[18:05] <MootBot> LINK received:  http://launchpad.net/~ubuntu-qa <-
[18:05] <LaserJock> yeah, I hadn't seen the last meeting minutes
[18:05] <cgregan> I'll take a look...thanks.
[18:05] <heno> ok no worries
[18:05] <LaserJock> but I perhaps have a bit different view of the team
[18:05] <LaserJock> I was hoping to sort of hammer that out today
[18:06] <heno> right, let's cover that on point 3
[18:06] <ara> hello all
[18:06] <ara> sorry for being late
[18:06] <heno> [TOPIC]: Posting on the QA blog - please sign it with your real name so readers can see where it's actually coming from
[18:06] <MootBot> New Topic: : Posting on the QA blog - please sign it with your real name so readers can see where it's actually coming from
[18:06] <heno> hey ara
[18:06] <heno> That topic is just a request really
[18:07] <sbeattie> It seems to use your id rather than your name, though, no?
[18:07] <heno> I know stgraber, nand and sbeattie post there fairly regularly
[18:07] <LaserJock> yeah, I noticed that because Planet Ubuntu just has "QA Blog" the posts seem kind of sterile
[18:07] <heno> yeah, just putting your name at the bottom would be good
[18:07] <sbeattie> LaserJock: actually, I peeked, it also has the authors id as well.
[18:08] <LaserJock> sbeattie: on the Planet Ubuntu feed?
[18:08] <LaserJock> or on the QA Blog feed?
[18:08] <sbeattie> LaserJock: at least when reading Planet Ubuntu via the google feed reader
[18:08] <LaserJock> I noticed when I actually went to the blog the UID is there
[18:08] <LaserJock> hmm, I didn't notice it, but I could have overlooked it
[18:09] <heno> I've never noticed it, but ok
[18:09] <LaserJock> in any case, I think it's nice for team blogs to "sign" the posts in the text
[18:09] <heno> it seems good practice
[18:09] <sbeattie> No argument there, making it more prominent would be good.
[18:10] <nand> ok, I'll do that from now on
[18:10] <LaserJock> I think it's important for people to see that QA is real people ;-)
[18:10] <LaserJock> not the mythical bots as some propose
[18:10] <heno> thanks
[18:10] <heno> [TOPIC]: Plans for ubuntu-qa Launchpad team and community QA efforts. (LaserJock)
[18:10] <MootBot> New Topic: : Plans for ubuntu-qa Launchpad team and community QA efforts. (LaserJock)
[18:10] <heno> we await a presentation :)
[18:11] <LaserJock> heh
[18:11] <davmor2> cool t'interweb presentations :D
[18:11] <LaserJock> ok, well I've sort of come to the QA arena in a round about direction
[18:12] <LaserJock> from MOTU/Edubuntu to MOTU SRU to "hmm, this QA stuff is pretty cool"
[18:12] <LaserJock> one of the things that's historically been difficult is sort of the Canonical/Community and related Main/Universe divide
[18:13] <LaserJock> so something I'm interested is in building the community side
[18:13] <LaserJock> and to sort of make the Main/Universe separation disappear
[18:14] <heno> perhaps it's more of a dev/non-dev divide than Canonical/community because we are quite active in the non-dev community
[18:14] <LaserJock> well, somewhat
[18:14] <heno> we should aim to close that too though
[18:15] <LaserJock> but for instance on your Key people page only 2 out of 12 people *don't" work for Canonical
[18:15] <LaserJock> historically the community hasn't really stepped up all that well when it comes to QA
[18:15] <heno> several of the QA initiatives have started in the forums, including iso testing and brainstorm
[18:15] <LaserJock> yes
[18:15] <davmor2> LaserJock: ahem ;)
[18:16] <LaserJock> the community shortage is particularly missing on the dev side
[18:16] <LaserJock> MOTU tend to work within themselves
[18:16] <heno> you mean https://wiki.ubuntu.com/QATeam/KeyPositions ?
[18:16] <LaserJock> we have http://qa.ubuntuwire.com where we've developed several good pages
[18:16] <LaserJock> heno: yes indeed
[18:17] <heno> 4 of 12, but the point is still valid
[18:17] <LaserJock> you sure? maybe some people have left, I just checked for @canonical on people's LP page
[18:17] <LaserJock> in any case
[18:18] <LaserJock> with a community as large as we have 4 just isn't really "stepping up" IMO
[18:18] <heno> yes, we'd like to work more with community developers
[18:18] <heno> agreed
[18:18] <LaserJock> so I'm interested in 1) bringing in QA-minded community people (primarily developer-minded personally)
[18:19] <LaserJock> 2) common infrastructure, forums, and namespace for Ubuntu QA efforts
[18:20] <LaserJock> so my proposal is to have the Ubuntu QA team represent not any person/team who do QA activities
[18:20] <heno> #1 I think we're all agreed on. #2 I agree with, but the devil is always in the implementation details
[18:20] <LaserJock> because that is really just about every person in the community, and is not really particulary useful
[18:20] <LaserJock> rather I'd like the Ubuntu QA to represent people who are interested in developing QA tools, procedures, and communities
[18:21] <davmor2> LaserJock: 1/ If you bring in dev-minded people the danger is that bugs are missed because they know what they are doing.  less dev-minded people are more likely to stumble
[18:21] <cgregan> As a non-dev tester...I agree
[18:21] <LaserJock> davmor2: well, I'm really not concerned with testing
[18:21] <LaserJock> I can let people who are worry about that
[18:22] <heno> LaserJock: but an 'Ubuntu QA' team would be
[18:22] <LaserJock> heno: no
[18:22] <LaserJock> they would really on be interested in developing communities of testers
[18:22] <heno> then what would it represent?
[18:22] <LaserJock> so currently we have the bugsquad to do bug triage
[18:22] <heno> leading by example often works best though
[18:23] <LaserJock> sure
[18:23] <LaserJock> so we need testing minded people in the team for sure
[18:23] <LaserJock> it's just not my particular forte, is what I'm saying
[18:23] <LaserJock> going back to the bugsquad
[18:23] <LaserJock> we already have a team for that
[18:23] <LaserJock> what we need is people who build the tools and procedures for triage
[18:24] <LaserJock> and to make sure the community is healthy
[18:24] <LaserJock> QAing the QA, so-to-speak
[18:24] <ara> toolsmiths, you mean
[18:24] <LaserJock> some of that, but more
[18:24] <cgregan> ﻿LaserJock: Would bugsquad not be a sub-team of the greater Ubuntu-QA?
[18:24] <LaserJock> cgregan: not in my scheme, no
[18:25] <cgregan> We may want to consider another name for this team then....to avoid confusion.
[18:25] <LaserJock> the only sub-teams I see for Ubuntu QA right now are Canonical QA and ubuntu-qa-website-devel
[18:25] <heno> I'm not sure this reduces confusion, esp. if you call it the ubuntu-qa team in LP
[18:25] <LaserJock> there should be no confusion
[18:26] <LaserJock> actual QA work is being done by almost every person in the Ubuntu community
[18:26] <LaserJock> it's like having an Ubuntu Contributor team
[18:26] <LaserJock> well, yes, you can do that, but what's the point
[18:26] <cgregan> This is true but not in an organized/guided manner
[18:26] <heno> but there will be. we already have an active team called Ubuntu QA, and you are proposing that some parts of that will not be included
[18:27] <LaserJock> heno: I've not seen that team
[18:27] <heno> LaserJock: you are at out meeting :)
[18:27] <heno> https://wiki.ubuntu.com/QATeam
[18:27] <LaserJock> exactly
[18:27] <LaserJock> but who's here?
[18:28] <LaserJock> I'm pretty sure every person active in this meeting would be in my Ubuntu QA team
[18:28] <heno> right, so an LP team would help show that
[18:28] <LaserJock> I'm just saying an umbrella QA team is rather useless
[18:28] <sbeattie> LaserJock: the point trying to be made is that cgregan and davmor2 don't consider themselves devs and would excluded by having ubuntu-qa be dev-oriented.
[18:29] <LaserJock> sbeattie: it's *not* dev-oriented
[18:29] <LaserJock> I'd like to see more dev people involved
[18:29] <LaserJock> so here would be my criteria for memebership:
[18:29] <LaserJock> 1) are you currently doing QA activity, triage, testing, etc. ?
[18:30] <LaserJock> 2) do you have a plan for developing Ubuntu QA efforts more?
[18:30] <LaserJock> that's mostly it
[18:30] <heno> joined with And or Or ?
[18:30] <LaserJock> AND
[18:30] <cgregan> That all sounds ok.
[18:30] <davmor2> 1/ Am I missing the point here did you not say that triaging (ie bug squad) wouldn't be part of the QA team?
[18:31] <LaserJock> bug squad isn't
[18:31] <heno> so that excludes people doing grass roots QA
[18:31] <LaserJock> heno: perhaps so, yes
[18:31] <LaserJock> but that can be fixed
[18:31] <heno> I'm happy for such a team to be set up, but not to call it ubuntu-qa
[18:31] <heno> that needs to be more inclusive
[18:32] <LaserJock> davmor2: it would be people who are interested in developing tools, polcies for bug squad and develop the community. People like Pedro and Brian Murray
[18:32] <LaserJock> heno: why?
[18:32] <LaserJock> it has a low barrier to entry
[18:32] <davmor2> LaserJock: heno: I think that would be more of a QA-Leadership team
[18:33] <LaserJock> davmor2: there is definately that aspect
[18:33] <heno> a) because our current (non-LP) team already works that way and b) it's important for our community building
[18:33] <ara> QA is much more than dev. Not only dev-testers can leader a QA team
[18:34] <LaserJock> heno: a) there really isn't a team, you just call it that b) you don't have a community right now and just included everybody doesn't help
[18:34] <cgregan> I think there should be no barrier to entry. Simply you want to do all those things mentioned above, but may or may not have any experience. A gateway team as it were.
[18:34] <heno> LaserJock: depends how you define low - some people are happy to help test but not reshape our tools or procedures
[18:34] <LaserJock> heno: fine, I'm not stopping them!
[18:35] <cgregan> Access to tools and cases, wikis, etc.
[18:35] <LaserJock> there's just a big difference between doing QA and being in a QA team, IMO
[18:35] <heno> LaserJock: neither of those statements are fair or accurate
[18:36] <heno> translators are on translation teams
[18:36] <LaserJock> sure, but that's different
[18:36] <LaserJock> take a factory
[18:36] <LaserJock> *every* person is doing QA when they do their job well, etc.
[18:36] <cgregan> ﻿LaserJock: I see your point of view. But I think this is the difference we want to reduce or remove.
[18:37] <LaserJock> but the QA team makes sure that 1) the right policies and tools are in place and 2) the rules are being followed
[18:37] <cgregan> So an advisory board
[18:37] <LaserJock> we already have a lot people doing QA activities, every developer, tester, triager, etc.
[18:37] <heno> in the software industry QA teams to testing and triage too
[18:37] <davmor2> LaserJock: But then what team do they belong to.  As I see it the people with the most access to the community and canonical for shaping, tools etc are people employed by Canonical.  So the team your suggesting automatically rules out the community because everything they would want to do would need to be run by the canonical employees
[18:37] <LaserJock> heno: yes, I agree
[18:38] <LaserJock> davmor2: that's absolutely not true
[18:38] <LaserJock> davmor2: the community can do virtually everything a Canonical employee can
[18:38] <LaserJock> and they *should* be able to do the rest and most of that is being worked on
[18:39] <LaserJock> heno: but this is a community, not the software industry
[18:39] <davmor2> LaserJock: I don't mean like that I mean as a voice ie Jono speaks and the world listens I speak and the people who know me listen
[18:39] <LaserJock> heno: it's a tad different
[18:39] <LaserJock> heno: i.e. we have lots of people to do the "grunt" work, if we can organize them and give them the tools
[18:40] <heno> LaserJock: so what is your reference point?
[18:40] <LaserJock> for instance, sbeattie shouldn't be actually doing SRU verification
[18:40] <cgregan> LaserJock: We are getting close. I deal with companies all day that want testing output and policies that match the "industry" so I have to guide my testers to do things that way.
[18:40] <LaserJock> he should be building the SRU tracking tools (which he is, and that's awesome) and the community to test
[18:40] <LaserJock> cgregan: well, that is regressive, IMO, but I understand your constraints
[18:41] <heno> LaserJock: but he has to step in ad do it if no one else does, and he has to do it now to learn how
[18:41] <cgregan> I agree but a compromise is likely here
[18:41] <LaserJock> heno: agreed, totally
[18:41]  * davmor2 head explodes
[18:41] <LaserJock> heno: but the focus should be on building the community, tools, and procedures
[18:42] <LaserJock> my problem with an umbrella team is it is going to be almost usless in this case
[18:42] <heno> LaserJock: why exactly are you opposed to picking a different name for the qa-tools-and-procedures team?
[18:42] <LaserJock> we have diverse groups of people, and a lot of them
[18:42] <LaserJock> heno: because I don't see the point of an umbrella Ubuntu QA team
[18:42] <heno> when it clearly conflicts with an existing team
[18:42] <LaserJock> there is no existing team
[18:42] <heno> but others do
[18:43] <davmor2> LaserJock: Am I missing the point...  That's what this team is doing the difference is at the moment we are also the community so we build tools to use and use them.....
[18:43] <heno> repeating that doesn't make it true
[18:43] <LaserJock> the "team" is Canonical QA and loosly calling any team doing QA work a part of "Ubuntu QA"
[18:43] <heno> not true
[18:43] <LaserJock> but it is not organized and most of it's members don't even know the team exists
[18:43] <LaserJock> so I'd hardly call it a team in reality
[18:44] <LaserJock> I'd like to put some meat to it
[18:44] <heno> it's not well enough advertised, that's true
[18:44] <LaserJock> ok, so who is in this team?
[18:44] <heno> and more meat would be good too, but we cant start by excluding current members
[18:45] <davmor2> me
[18:45] <cgregan> ﻿LaserJock: Perhaps the solution is as heno hints...more advertising of existing teams. Perhaps by this new team. Whatever it is to be called.
[18:45] <LaserJock> heno: excluding who?
[18:46] <LaserJock> a more defined team gives you the chance to use bzr branch hosting
[18:46] <LaserJock> allows you to possibly use PPAs
[18:47] <LaserJock> it allows you to bring people together
[18:47] <LaserJock> without bothering people who wouldn't care
[18:47] <heno> LaserJock: exclude people who just want to help with QA work
[18:47] <davmor2> LaserJock: That would probably also be me.  Being that I have no to little technical knowledge or development skills but who is also called on by lots of team leads to test stuff for them.
[18:47] <LaserJock> heno: but it doesn't exclude them from doing the work
[18:47] <heno> sure, there are technical benefits to an LP team, I don't oppose that
[18:48] <LaserJock> this is very similar to ubuntu-dev
[18:48] <bdmurray> davmor2: I believe you are writing documentation for testing which is a valuable contribution to a team like this
[18:48] <LaserJock> we have ubuntu-dev as a smaller group of people who focuse on developing packages
[18:48] <LaserJock> they write policies, do testing, etc.
[18:49] <heno> bdmurray: right but he stated out helping with testing, as did stgraber
[18:49] <LaserJock> but that doesn't exclude people from doing development work
[18:49] <LaserJock> on the contrary it gives people something to work towards, and it gives tremendous support to the vast community of people contributing to development
[18:50] <heno> ok, I don't think we are going to reach consensus on this today and we have another topic
[18:50] <LaserJock> k
[18:50] <bdmurray> Where should we continue the discussion then?
[18:50] <heno> LaserJock: do want to write up your proposal on a wiki page perhaps?
[18:50] <LaserJock> well, I try to work on more of a written proposal/description of what I'm thinking
[18:50] <LaserJock> yeah
[18:50] <heno> ok, thanks
[18:51] <heno> [TOPIC]: 8.04.1 ISO testing status
[18:51] <MootBot> New Topic: : 8.04.1 ISO testing status
[18:51] <heno> http://iso.qa.ubuntu.com/qatracker/build/all/all has the current status
[18:51] <MootBot> LINK received:  http://iso.qa.ubuntu.com/qatracker/build/all/all has the current status
[18:53] <sbeattie> heno: you said you were going to tackle more difficult cases, did you try xubuntu/encrypted LVM ?
[18:53] <heno> the DVDs still need some work, Edubuntu and Xubuntu
[18:53] <heno> sbeattie: I have yes
[18:53] <ara> i have been some testing on ubuntustudio against virtualbox. i would like to test it again because it seems to consume much memory
[18:53] <heno> more obscure cases at least
[18:53] <ara> how much memory should I allocate in the vbox for that case?
[18:54] <heno> ara: during install, or running?
[18:54] <ara> during the install
[18:54] <ara> when choosing all the options
[18:54] <heno> 128 should be enough for a d-i install
[18:54] <ara> if i choose less options it finishes correctly
[18:54] <heno> I used 384 though
[18:54] <heno> ara: does it halt?
[18:55] <ara> yep
[18:55] <ara> it halt twice, actually
[18:55] <ara> it only finished corretly once, when not choosing all of the options
[18:55] <ara> apart of that, the installation process is text-based; is that normal in ubuntu studio?
[18:56] <heno> can you restart it when it halts or is it completely dead?
[18:56] <ara> dead
[18:56] <heno> apt does consume memory linearly
[18:57] <heno> so very large upgrades have the same problem
[18:57] <heno> how much ram did you give it?
[18:57] <ara> mm, not sure, let me check
[18:57] <ara> 256MB
[18:59] <heno> bdmurray: where would one file such a bug - I guess it's ubuntu studio documentation issue?
[18:59] <ara> i will check again early tomorrow, but it would be nice if you could check that too
[18:59] <ara> 256MB RAM, choosing all the available packages
[18:59] <heno> I will, though it's not likely it will be fixed for Hardy.1
[19:00] <bdmurray> heno: it depends on where the minimum recommended amount is documented
[19:00] <heno> it may of course be a real d-i bug or something
[19:02] <heno> anyway, I'll do a bit more testing this evening and would ask others to do the same :)
[19:02] <heno> ATM it looks fine for release tomorrow
[19:02] <heno> any other topics?
[19:03] <heno> ok, thanks everyone!
[19:03] <heno> #endmeeting
[19:03] <MootBot> Meeting finished at 13:04.
[19:04] <ara> thanks
[19:04] <ara> bye
[19:04] <sbeattie> thanks
[19:04] <pedro_> thanks
[19:07] <davmor2> ta
[23:00] <cjwatson> good evening folks
[23:00]  * ogra waves
[23:00] <asac> second
[23:00] <asac> hi all
[23:00] <liw> yo
[23:00] <calc> hi
[23:00] <TheMuso> hi
[23:01] <cjwatson> ubottu's clock is slow
[23:01] <slangasek> morning :)
[23:02] <bryce> heya all
[23:02] <cjwatson> right, I have sufficiently little on my list today that I didn't get round to mailing out an agenda; sorry for that - I do have a few items though, then I'll throw it open to the floor
[23:03] <cjwatson> firstly (and this one is only relevant for Canonical staff) the distro team managers have agreed that distro-team@ would become more useful if each team collected activity reports privately and then included them in its meeting summaries
[23:03] <cjwatson> there are some disadvantages, mostly that it means we can't follow up to individual activity reports as easily, but on the whole I think I agree it would make the list more bearable to follow
[23:04] <james_w> hi all
[23:04] <asac> sounds reasonable. how would we collect them privately? on a wikipage?
[23:04] <ogra> its not actually high traffic though
[23:04] <TheMuso> ogra: Agreed.
[23:05] <cjwatson> so I'd like to ask that you mail me activity summaries at the end of your day on TUESDAY in order that I can collect them and stick them on a wiki page or something, and then they can go into the agenda
[23:05] <cjwatson> ogra: I'm afraid many people do disagree
[23:05] <cjwatson> we have getting on for 50 people, and it adds up pretty quickly
[23:05] <ogra> heh, well, i read ubuntu-users... i might have different views through that :)
[23:06] <evand> hi
[23:06] <cjwatson> this also means that at least parts of activity reports that are public can easily be posted on ubuntu-devel, which I think would be fairly useful
[23:06] <cjwatson> or at least links to them
[23:07] <asac> how about an activity mailing list where the reply-To is set to distro team?
[23:08] <bryce> while it causes traffic, it's sort of nice having each person's status report as a separate email, since it makes it easy to pick and choose which reports to read.  With them all concatenated together, I think it would be more work and I'd be less inclined to look at any of them
[23:08] <liw> asac, that still means people get a lot of mail -- unless most people aren't on the new list, in which case it's fairly pointless, imho
[23:08] <cjwatson> right now, I know that I simply don't bother reading status reports from other teams, and I'd like to fix that; if I just had to read meeting reports it would be a lot easier
[23:09] <cjwatson> it's the same amount of text, but less intimidating in one's mailer
[23:09] <liw> cjwatson, as it happens, I have the opposite feeling: long mails are harder and more intimidating to me
[23:09] <calc> hmm didn't we used to have a activity mailing list?
[23:09]  * liw gets antsy if he can't press Delete every five seconds
[23:09] <slangasek> bryce: well, I take the converse view that, since the name of the sender doesn't tell me if there's interesting activity to read about, it makes my mailbox much larger to have them each as separate mails :)
[23:09] <calc> then they wanted it moved to distro-team now its too much traffic? ;-)
[23:10] <ogra> calc, but for the whole company
[23:10] <slangasek> maybe they should be concatenated into MIME digest form ;)
[23:10] <cjwatson> I would like us to try this out for a while; if it causes serious problems, we can revert
[23:10] <calc> ogra: ah ok
[23:10] <slangasek> then you can delete MIME subparts that you're done with :)
[23:10] <cjwatson> calc: it became unusable once the company grew beyond about 40 or so
[23:10] <liw> I'd me more in favor of people writing _shorter_ activity reports :)
[23:10] <calc> liw: do less work? :)
[23:10] <ogra> ++
[23:10] <TheMuso> liw: I don't think thats always possible, due to the nature of what some of us are doing.
[23:10] <liw> otoh, collected activity reports could be formatted more systematically, which would help
[23:10] <cjwatson> Not shorter for the sake of it, but concise
[23:11] <cjwatson> with this system, I will be happy to do some trivial reformatting to bang 'em all into the same style
[23:13] <cjwatson> secondly: many of the packages in the partner archive (archive.canonical.com) have been constructed by folks without lots of experience in the Ubuntu project, and yet if Ubuntu users enable that archive those packages are presented to them
[23:13] <cjwatson> I'd like to arrange for a brief retroactive review of those packages for quality, and have agreed with the relevant manager that this is something that would be accepted
[23:14] <cjwatson> would anyone like to volunteer to help out? the number of packages is not terribly large
[23:14] <TheMuso> I don't mind helping out.
[23:14] <cjwatson> I think it should take maybe 15 minutes per source package, tops
[23:14] <asac> cjwatson: how many packages are there atm?
[23:14] <cjwatson> $ zcat /srv/launchpad.net/ubuntu-archive/ubuntu-partner/dists/*/*/source/Sources.gz | grep ^Package | wc -l
[23:14] <calc> so nothing huge like symphony then? ;-)
[23:14] <liw> I could do a couple
[23:14] <cjwatson> 38
[23:15] <cjwatson> $ zcat /srv/launchpad.net/ubuntu-archive/ubuntu-partner/dists/*/*/source/Sources.gz | grep ^Package | sort -u | wc -l
[23:15] <cjwatson> 10
[23:15] <slangasek> I'd be willing to help
[23:15] <cjwatson> some of them are large, but I'm not expecting very deep review of the upstream code (we may not have it, in any case)
[23:15] <TheMuso> I think its a matter of making sure they are packaged correctly for a start.
[23:15] <cjwatson> yes
[23:16] <calc> how do we coordinate what has been reviewed by whom?
[23:16] <cjwatson> this will also help to provide some mentoring for the people doing this work
[23:16] <cjwatson> I think it's simplest if I just assign them out
[23:17] <cjwatson> ACTION: cjwatson to assign partner package reviews to volunteers
[23:17] <cjwatson> so I have Luke, Lars, Steve, Alex?, Chris?
[23:17]  * calc volunteers to look at them
[23:17] <cjwatson> should be fine
[23:17] <cjwatson> thirdly: slangasek, any good or bad news about 8.04.1?
[23:17] <asac> i didnt opt in explicitly, but feel free to assign reviews to me :)
[23:17] <cjwatson> ok, thanks
[23:19] <slangasek> 8.04.1 is coming on very well, for all the (typical) last-minute rush of fixes.  We still have a couple of SRUs that are on the CDs right now by virtue of building out of -proposed which have still not made it through the SRU verification process, so those need to be sorted in short order
[23:19] <slangasek> one of them is a bug asac will be familiar with, bug #219587 in cairo
[23:20] <slangasek> that's certainly the riskiest of the SRUs that we have left, but all things considered I think there's insufficient evidence of regressions to block it and force a reroll of all images
[23:20] <slangasek> so - if anyone has noticed that cairo is behaving funny, speak up now :P
[23:20] <slangasek> otherwise, ISO testing has been going *very* well
[23:20] <asac> slangasek: how can we reach a consent here? i think seb is all for that patch. i am not sure.
[23:21] <slangasek> if anyone has some spare cycles today (or tomorrow for European time), more ISO testing may still be of help; please coordinate with #ubuntu-testing on this to find out where help is needed, so we don't have 5 people all independently downloading the same image for one test
[23:22] <asac> err, s/all for/all against/
[23:22] <slangasek> asac: sorry, seb is against the patch?  I haven't seen this said anywhere in the bug log...
[23:23] <slangasek> in fact, I see comments from him saying that it works fine for him
[23:23] <evand> wouldn't we want as much coverage over each test as possible?
[23:23] <asac> slangasek: yeah he wants to drop the patch ;)
[23:23] <slangasek> evand: when you start starving the rsync server for bandwidth, you have your limit on how much coverage is possible ;)
[23:23] <slangasek> evand: so definitely coordinate with #u-testing, please
[23:23] <slangasek> asac: oh, that - yes :)
[23:23] <evand> ah, fair enough, and will do
[23:24] <slangasek> asac: well, my understanding is that we have only a single, unreproducible and uninvestigateable report of a regression that was correlated with the cairo update
[23:24]  * liw notes there's a bunch of ISOs on the tracker that don't yet have complete coverage, and one or two without any coverage
[23:24] <slangasek> asac: whereas everyone else has been running this update in -proposed for 28 days and there've been no other reports of regression, in spite of my prodding that people should be alert for this
[23:25] <slangasek> asac: so unless someone speaks up now and says it's broken, I intend to push it
[23:25] <calc> anyone noticed weird crashing that causes your machine to just turn off?
[23:26] <calc> i'm hoping my system isn't dying
[23:26] <TheMuso> calc: What sort of crashing?
[23:26] <liw> calc, what kind of crashing? an immediate shut-off?
[23:26] <ogra> blocked fan or something ?
[23:26] <slangasek> on a related note, we know we have a few high-priority SRUs to push out of the queue right on the heels of 8.04.1.  I'll be unfreezing -proposed shortly, but unfortunately won't have any time to process those SRUs myself until at least tomorrow
[23:26] <calc> using system just fine then instant power off
[23:26] <cjwatson> calc: it did rather sound like heat trouble to me, though it's hard to be sure
[23:27] <ogra> well, just monitor your temperature for a while
[23:27] <ogra> and you will know
[23:27] <calc> i wasn't doing anything at the time (at least today) to cause high heat output, unless its a fan issue or something
[23:27] <liw> calc, that sounds like heat or memory problems to me; you may want to run memtest overnight
[23:27] <nand> had similar issue with a deficient power supply
[23:27] <calc> ogra: ok
[23:27] <slangasek> I've had a system power itself off this week due to the heat... horrible Oregon weather :-)
[23:27] <calc> its in a laptop ran, memtest for an hour or so and occt on vista for about an hour
[23:27] <TheMuso> I've bee experiencing weird behiavor lately as well, but no instant power off.
[23:27] <ogra> yeah power supply could look like that as well
[23:27] <liw> I've had several cases of memtest only finding problems after 12 hours or so
[23:28] <calc> but i will have to watch the cpu temp to see what it shows for a while
[23:28] <calc> liw: ah
[23:28] <cjwatson> slangasek: I'll get you the bits of the release announcement I'm working on as soon as I can
[23:28] <slangasek> cjwatson: appreciate it, thanks
[23:28] <cjwatson> hopefully before I go to bed tonight
[23:28] <calc> it didn't start happening until June 26 and since it has been about once every 2 days
[23:29] <cjwatson> actions from last week: most I know are done or as done as they'll get, I think the only one I didn't hear about was bryce's libx11/libxcb action
[23:30] <calc> cjwatson: the OOo part of that issue was due to a xrandr heap corruption issue and has been fixed in hardy-updates now
[23:30] <cjwatson> there seems to be some contention at the tail of the bug report
[23:30] <calc> but there appears to be other issues that are really due to that problem(?)
[23:30] <bryce> cjwatson: I think we got the xcb stuff sorted out
[23:31] <bryce> we can't easily just drop xcb since compiz needs it
[23:31] <slangasek> the two critical manifestations of the xcb thing that I'm aware of were xubuntu login lockups and OOo/amd64, both of which have been sorted by other means
[23:31] <bryce> however, the xubuntu issue had a workaround identified that solved it
[23:31] <slangasek> (for hardy)
[23:31] <cjwatson> mm, the tail of the report suggests that there are still a number of other applications with similar problems; not critical, but I feel bad leaving it that way
[23:31] <calc> there's supposedly some java issue there too
[23:31] <cjwatson> there was a suggestion of providing a separate libX11-xcb for compiz to link against
[23:31] <calc> but i don't know details of it
[23:31] <bryce> and the OOo issue sounded like a workaround was identified there too, but I hadn't verified it as solved
[23:32] <calc> bryce: yea it was due to xrandr heap corruption
[23:32] <slangasek> doesn't compiz use other X-based libs? (== symbol collisions)
[23:32] <cjwatson> the Java issue is fairly well-known and fixed upstream, but you have to be running a pretty up-to-date JRE (I'm not even sure it's fixed in OpenJDK 6)
[23:32] <bryce> calc, ok
[23:33] <cjwatson> mm, fair point - there's already both libX11.so.6 and libX11-xcb.so.1, I'm assuming that libX11 itself has to be built such that it will load libX11-xcb?
[23:34] <slangasek> looks like libX11-xcb loads libX11
[23:34] <cjwatson> if there is an environment variable workaround (I know some of these issues can be worked around with LIBXCB_DISABLE_SLOPPY_LOCK=1, but I'm not sure if all of them can) then reminding folks of that would help
[23:35] <cjwatson> the original bug report looks different from the ones I've seen before, though
[23:35] <bryce> given that we've been able to workaround the issues discovered so far, I don't think there's a pressing need at this point to ship variant libx11's
[23:36] <bryce> however if other issues crop up that can be proven to be unfixable any other way, I'd still definitely be open to that route
[23:36] <slangasek> the xcb-enabled libX11.so.6 doesn't use symbol versions today; trying to clear up symbol collisions between compiz and its libs would require a rebuild of the whole dep chain, /after/ the work to actually add symbol versions, and this whole plan would also need to be passed by upstream to verify that it's even possible to use both X11 libs from the same process
[23:36] <slangasek> (they might try to overrun each other's state via env vars or something)
[23:37] <cjwatson> bryce: could you follow up with the people who have reported problems after your wontfix status change, and make sure that we can deal with them?
[23:37] <bryce> cjwatson: sure, will do
[23:37] <cjwatson> slangasek: ok, sounds ridiculously infeasible then
[23:37] <cjwatson> I have nothing else for this meeting; anyone have anything they want to bring up?
[23:38] <calc> i have a question
[23:38] <cjwatson> either problems, or particularly good news for a change ;-)
[23:38] <calc> is there an easy way to branch into a subdir of a bzr repo
[23:38] <calc> i hear merge-into might be the way
[23:38] <calc> for OOo i have a top level dir then there is debian and ubuntu dirs under that
[23:39] <calc> debian's OOo bzr repo has the top level being their debian dir
[23:39] <bryce> xserver 1.5 + new mesa + new libxrm + new xorg + rebuild of all drivers is coming within a week or so
[23:39] <cjwatson> calc: firstly, I completely concur with lifeless that you would be best advised to leave it the way it is for the moment
[23:39] <calc> cjwatson: ok, status quo is that i have merge each time, just want to make sure i was clear about that before :)
[23:39] <calc> i pull a diff between old and new versions of debian repo and then merge the results by hand into our repo
[23:39] <cjwatson> um
[23:40] <cjwatson> does bzr merge not work for some reason? why not?
[23:40] <calc> well that is my question, can i use bzr merge when the trees aren't the same
[23:40] <cjwatson> can you give a pointer to the two trees so I can have a quick look?
[23:40] <slangasek> well, you can use it unless it tells you "no common ancestor"
[23:40] <ogra> if the ancestor is the same you can
[23:40] <calc> top level of ubuntu's tree is the package dir (eg ooo-3.0) on debian it is (ooo-3.0/debian)
[23:40] <slangasek> so you get feedback pretty quick if you try :)
[23:40] <calc> yea
[23:40] <james_w> calc: sorry I hadn't replied
[23:40] <slangasek> you just may have to fix a lot up the first time you run it, if you've been merging by hand 'til now
[23:41] <calc> http://bzr.debian.org/pkg-openoffice/packages/openofficeorg/2.4.1/unstable/
[23:41] <cjwatson> oh, I see, you've done *that*
[23:41] <slangasek> oh, eep
[23:41] <calc> https://code.launchpad.net/~openoffice-pkgs/openoffice/2.4.1-hardy
[23:41] <calc> james_w: np
[23:41] <cjwatson> personally, were I in that situation, I would be inclined to reconstruct the branch revision by revision (automatically) such that ubuntu/ was under debian/ubuntu/ instead
[23:41] <calc> slangasek: i was planning on starting over for 3.0-intrepid branch
[23:42] <cjwatson> but I appreciate you may not want to do that
[23:42] <calc> slangasek: and doing the merge once after getting it branched properly
[23:42] <slangasek> calc: "starting over" -- this is not the DVCS future *I* was promised :)
[23:42] <calc> cjwatson: ah stick the ubuntu dir under debian dir?
[23:42] <cjwatson> calc: in giving advice here, I'm torn between the fact that your current layout is actually closer to where we want to end up, and the practicalities of merging usefully from Debian right now
[23:43] <calc> well if i did that and preserved history (the nice way) then i would have to change code or the old versions wouldn't actually work
[23:43] <calc> since the dir will have moved
[23:43] <cjwatson> yes, that's true, and that would be pretty bad I agree
[23:43] <calc> there is this thing that sounds like it might work called merge-into but it seems still beta'ish
[23:43] <cjwatson> bzr join/split and merge-into are the only things I'm aware of that allow you to treat directories within branches as if they were branches themselves
[23:43] <slangasek> evand: is bug #245010 a regression vs. 8.04?
[23:44] <james_w> I haven't looked in detail yet, but it does sound like what "merge-into" is meant to do, but that does have some problems.
[23:44] <cjwatson> and, afaik, both of those are fairly beta
[23:44] <calc> james_w: ah ok
[23:44] <calc> i may just do the ugly debian/ubuntu subdir for now then it would probably be safer
[23:44] <james_w> calc: the main problem I've seen is that it get's confused when files are added in the future. which I expect is reasonably common.
[23:44] <calc> s/then/since/
[23:45] <calc> james_w: yea
[23:45] <slangasek> cjwatson: I've previously been assured that bzr merge/join is safe for use
[23:45] <evand> slangasek: No, it's a usability problem.  He chose to format the entire disk, which means migration-assistant cannot do anything so ubiquity doesn't show the m-a page.
[23:45] <cjwatson> calc: you might actually be better off leaving it alone right now, and talking with John Meinel about merge-into
[23:45] <slangasek> and the grub packaging branch is built with merge/join :)
[23:45] <james_w> calc: I'm grabbing the branches now, I'll put together an email tomorrow for you if that's ok?
[23:45] <calc> also since debian branches off when they make a new release how do i make mine properly follow that?
[23:45] <slangasek> evand: ok, thanks for confirming
[23:45] <cjwatson> I certainly wouldn't do anything in this case without having a Bazaar developer advise you (james_w would count of course)
[23:45] <calc> cjwatson: ok
[23:46] <calc> james_w: ok that will be great :)
[23:46] <cjwatson> slangasek: oh, cool - though the repo format required for merge/join is as I remember still not the default
[23:46] <slangasek> oh, it may still not be default
[23:46] <cjwatson> calc: if Debian creates a branch based on the previous one, then you can simply merge that branch
[23:46] <slangasek> I'm not sure
[23:47] <slangasek> but I was told to use it, and it works happi :)
[23:47] <calc> cjwatson: ok
[23:47] <cjwatson> (once you get merging sorted, period)
[23:47] <cjwatson> calc: since that new branch will include all the relevant history
[23:47] <calc> cjwatson: oh once you have merged up to the old branch you just specify the url to the new branch to merge it?
[23:47] <cjwatson> yes
[23:47] <calc> ah cool :)
[23:48] <cjwatson> and you can use --remember if you want to make it the new default merge location
[23:48] <calc> ok
[23:48] <cjwatson> james_w: I've filed an RT for your importer machine, BTW, and will be chasing it with IS probably tomorrow to get a timeline
[23:48]  * liw wants a --remember option for his home keys
[23:48] <TheMuso> heh
[23:49] <cjwatson> james_w: RT #31152
[23:49] <james_w> cjwatson: yes, I saw, thanks.
[23:49] <bryce> how do you tell bzr your lp username differs from your login name?
[23:49] <cjwatson> oh yes, I did remember to CC you
[23:49] <cjwatson> bryce: bzr launchpad-login
[23:49] <ogra> and in the config file
[23:49] <cjwatson> bryce: also, setting it in ~/.ssh/config is a good idea
[23:49] <cjwatson> Host bazaar.launchpad.net
[23:49] <cjwatson>         User kamion
[23:49] <cjwatson>         ControlPath none
[23:49] <cjwatson> in my case
[23:50] <cjwatson> (err, you can possibly ignore the ControlPath none bit)
[23:50] <ogra> .bazaar/bazaar.conf knows launchpad_username as well
[23:50] <ogra> tats where i set it
[23:50] <bryce> ahh thanks, looks like putting into ~/.ssh/config did the trick
[23:51] <cjwatson> ogra: that's what bzr launchpad-login reads/writes
[23:51] <ogra> ah, i wasnt aware :)
[23:51] <ogra> i set it manually a while ago
[23:51] <cjwatson> ok. any other business?
[23:52] <bryce> I mentioned the pending xserver merge.  We know this breaks compiz on -intel and brings some other problems, which we'll be working on in the coming weeks.
[23:53] <cjwatson> sorry, I missed that earlier
[23:53] <cjwatson> what shiny things do we get with 1.5?
[23:53] <bryce> after the base merge is in, we'll also be switching on input-hotplug
[23:53] <cjwatson> and anything that developers should watch out for?
[23:54] <bryce> for new things, this is mostly a bug fix; most of the sexy changes got put off
[23:54] <ogra> bah
[23:54] <bryce> the major change will be switching to pciaccess, which *hopefully* should be an invisible change, but probably won't
[23:55] <cjwatson> might be worth warning the QA team of likely symptoms
[23:55] <ogra> does that mean we wont have such silly situations like the last week anymore  with shuffling pci ids etc ?
[23:55] <bryce> watch out for the usual stuff... performance degradation, failure to start X, input device oddities, etc.
[23:56] <slangasek> ogra: pciaccess is just a different layer for interfacing with PCI, it AFAIK doesn't change the fact that drivers still need to declare the PCI IDs they support...
[23:56] <bryce> ogra: it'll be a different procedure, but I don't expect it will necessarily prevent such situations
[23:57] <ogra> that would be awesome
[23:57] <bryce> ogra: for the major drivers I don't think there'll be issues, but with drivers that don't get a lot of developer attention upstream, we may see regressions there
[23:57] <ogra> we all lost a lot of time for such a trivial change
[23:57] <bryce> ogra: agreed
[23:58] <calc> so watch out for bugs in SiS ;-)
[23:58] <cjwatson> ... so, if you're running something other than intel,ati,nv, please test intrepid ...
[23:58] <slangasek> bryce: is matrox ported yet? I need to re-test on my alpha ;)
[23:58] <bryce> ACTION:  bryce to let cr3 know to test many different drivers after the pciaccess change goes through
[23:58] <bryce> slangasek: knock yourself out ;-)
[23:58] <cjwatson> slangasek: using the well-known Ubuntu alpha port
[23:58] <ogra> heh
[23:59] <slangasek> cjwatson: this week I used an alpha as a door stop for the first time
[23:59] <slangasek> sad day
[23:59] <asac> lol
[23:59] <slangasek> (also, a hot and windy day)
[23:59] <ogra> if yu want to get rid of one, i have plenty of space :)
[23:59] <bryce> cjwatson: nothing else from me on the X front.  Just want folks not be surprised that there'll be a sudden change in X
[23:59] <cjwatson> OK, thanks for the update
[23:59] <cjwatson> other than that, we're at the one-hour mark, so let's adjourn
[23:59] <bryce> thanks
[23:59]  * liw sees "DEC AlphaPC 164 500 MHz 1 MB cache 2*32/33 2*64/33 PCI 2*ISA 8*SIMM 59.06 e" on the web pages for his favorite computer store...