[01:25] <boxdotsk> trying to figure out how to do the dancing icons
[04:16] <Hobbsee> nixternal: almost in luck, then.
[05:14] <nickellery> @schedule Vancouver
[07:55] <\sh> Seveas: can you please send ubottu to #leonov :) thx
[09:00] <jussi01> \sh: Ummm, seveas doesnt run ubottu - I do. what is #leonov?
[09:01] <\sh> jussi01: launchpad desktop client..
[09:14] <riot_l1> \sh: do you upload the code or a package to Launchpad yet?
[09:14] <\sh> riot_le: launchpad.net/leonov :)
[09:16] <riot_le> \sh: great idea
[09:18] <\sh> riot_le: yes...since launchpad was born I had this idea :)
[09:21] <riot_le> \sh: what do you think how long will it take, till its usable?
[09:22] <\sh> riot_le: depends...we have some things still to do...some other things we have to implement in py-lp-bugs, but thekorn rocks in doing this ;) hopefullly I'll have for the kde part a working bug info display this evening
[09:22] <\sh> well...real life and real money work sucks ;)
[09:23] <riot_le> thats true :-)
[17:59] <pedro_> hey hey
[17:59] <heno> hey everyone
[18:00]  * stgraber waves
[18:00] <bdmurray> hi
[18:01] <heno> wow we have a Fridge entry :)
[18:01] <stgraber> yeah, rocks
[18:01] <pedro_> yeah!
[18:01] <heno> sbeattie, cgregan: around?
[18:01] <davmor2> congrats :)
[18:01] <cgregan> here
[18:01] <heno> hey davmor2
[18:02] <davmor2> heno: hello :)
[18:02] <heno> ok, let's start
[18:02] <heno> #startmeeting
[18:02] <MootBot> Meeting started at 12:05. The chair is heno.
[18:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:02] <heno> \o/
[18:03] <heno> [TOPIC]: Hardy.1 SRU verification
[18:03] <MootBot> New Topic: : Hardy.1 SRU verification
[18:03] <sbeattie> hey
[18:04] <heno> Here is a nice tracker sbeattie and LaserJock have been working on http://people.ubuntu.com/~sbeattie/sru_todo.html
[18:05] <heno> some of the major packages like linux, openoffice and ltsp have been tested and seem good
[18:05] <heno> firefox 3.0 was also released today
[18:06] <heno> one area of concern is pulseaudio/alsa
[18:06] <heno> sbeattie: do you have a view on that
[18:06] <heno> ?
[18:06] <heno> it's an area where we need to appeal for more testing I think
[18:06] <sbeattie> heno: in terms of?
[18:07] <sbeattie> Yes, I believe it's an area where we should appeal for testing.
[18:07] <heno> sbeattie: what were the concerns expressed at last week's .1 meeting?
[18:07] <heno> or is there a log I can look at?
[18:08] <sbeattie> alsa/pulseaudio has a lot of problems as released, probably due to version mismatch between alsa's userspace and kernel.
[18:08] <heno> what are the concerns about the new versions?
[18:09] <heno> just that they are undertested?
[18:09] <davmor2> sbeattie: is that the cause of somethings playing in wrong speakers if two audio apps are running?
[18:09] <heno> and that it's a major change?
[18:09] <sbeattie> davmor2: that I don't know.
[18:10] <sbeattie> Yes, that it's a major upgrade for the userspace component, from 1.0.15 to 1.0.16.
[18:10] <pedro_> new version aka alsa 1.0.16 ?
[18:10] <pedro_> there's a resume about it here: https://bugs.edge.launchpad.net/ubuntu/+source/pulseaudio/+bug/221673/comments/16
[18:10] <pedro_> seb128 talked with jordi about it and send us an IRC log which slangasek resume on that comment
[18:10] <pedro_> s/send/sent
[18:11] <heno> ok, thanks. that sheds some light
[18:12] <heno> has mgunes been around lately? This would be a good item to bring to the forums
[18:12] <slangasek> recently, there's an additional concern that the new alsa-lib causes regressions for xubuntu as well
[18:12] <slangasek> which bug I cannot currently find
[18:13] <cody-somerville> mmm
[18:13] <cody-somerville> I didn't see that bug either
[18:13] <sbeattie> the last comment in 221673 perhaps?
[18:13] <sbeattie> oh right, bug 240337
[18:14] <davmor2> http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg884888.html
[18:14] <MootBot> LINK received:  http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg884888.html
[18:14] <heno> so what is most needed here, general testing or better debugging information on know issues?
[18:14]  * heno suspects the answer is 'both' :)
[18:15] <sbeattie> I think that's right.
[18:15] <sbeattie> :-)
[18:15] <davmor2> or maybe a more standard way of testing for the upgrades?
[18:16] <heno> davmor2: yes we need that too. We could use your help on improving https://wiki.ubuntu.com/QATeam/PerformingSRUVerification :)
[18:16]  * davmor2 looking
[18:16] <heno> to be as user friendly as the new test case pages
[18:17] <heno> Ok, I'll read some logs and bugs about know issues and appeal for wider testing
[18:17] <sbeattie> davmor2: did you mean in particular about testing alsa?
[18:17] <davmor2> heno: that's just scary :-/
[18:18] <heno> sbeattie, slangasek: anything else we should note about the remaining SRUs?
[18:18] <sbeattie> Because that would perhaps be useful, drawing up some specific things to test.
[18:18] <davmor2> sbeattie: no as a whole
[18:18] <slangasek> heno: nothing off the top of my head, no
[18:19] <sbeattie> other areas that we could use help verifying fixes are some of the wubi/installer related bugs.
[18:19] <heno> I see there are some installer/wubi/migration-assistant issues
[18:19] <davmor2> sbeattie: My point is it's okay to install -proposed but if you hardly use the apps that get updated you'll never know if there are any issues :)  Hope that makes sense
[18:19] <heno> ... :)
[18:19] <sbeattie> lupin, migration-assistant, casper.
[18:20] <davmor2> is there an updated version that can be dropped on a cd now rather than recompiling a version and I can test that then?
[18:20] <heno> davmor2: right, the bugs linked from http://people.ubuntu.com/~sbeattie/sru_todo.html should have test cases
[18:20] <heno> that brings us to CD testing :)
[18:20] <sbeattie> otherwise, the list of things needing verification has been pared down quite well, in part thanks to heno and stgraber for verifying openoffice and ltsp respectively.
[18:21] <sbeattie> yes, cd testing, when I started to do some installer verification testing last week, I found the alternatives cd was broken
[18:21] <heno> these are not built from proposed I guess http://cdimage.ubuntu.com/hardy/daily/current/
[18:21] <sbeattie> slangasek fixed it, but we need to some smoke testing of what's getting built.
[18:21] <heno> that might be useful in the future
[18:22] <sbeattie> There's some isos being built from proposed...
[18:22] <slangasek> heno: they are built from proposed
[18:22] <heno> ah, very cool
[18:23] <davmor2> slangasek: are these the iso that will be put forward as .1 or alpha 1 or both?
[18:23] <sbeattie> .1
[18:23] <slangasek> they're under /hardy/ - they have nothing to do with intrepid :)
[18:23] <heno> [TOPIC]: 8.04.1 ISO testing
[18:23] <MootBot> New Topic: : 8.04.1 ISO testing
[18:23] <davmor2> Ah right np's :)
[18:24] <heno> (just for the bookkeeping :) )
[18:24] <heno> davmor2: both need testing, and hardy.1 more strictly
[18:24] <davmor2> No probs heno.
[18:24] <heno> stgraber says we can list both on the tracker
[18:25] <davmor2> that's cool :)
[18:25] <sbeattie> slangasek: are the other *buntus getting built for .1 as well?
[18:25] <slangasek> yes
[18:25] <sbeattie> excellent
[18:25] <slangasek> but not until we fix a buglet introduced by removing packages from -proposed
[18:26] <sbeattie> oh, they're failing to build now?
[18:26] <stgraber> heno: it's indeed possible to do it, I must admit not having tested that for a long time :)
[18:27] <slangasek> actually, they /were/ failing to build, now they just need an archive fix; sorry, my explanation above was ill-informed and buggy :)
[18:27] <sbeattie> Heh, no problem, thanks for clarifying
[18:27] <heno> so we should do some light smoke testing of the current hardy.1 CDs and then do more full coverage as we get final-candidate images
[18:27] <sbeattie> agreed
[18:28] <davmor2> heno: when are the FC cds going to be around?
[18:28] <sbeattie> Is https://wiki.ubuntu.com/Testing/Isoscript still useful for keeping daily images current?
[18:28] <sbeattie> as far as anyone knows?
[18:28] <LaserJock> is there a list of all the updates/bugs fixed on the .1 ?
[18:28] <davmor2> sbeattie: it will be if you change directories
[18:29] <heno> indeed, we should study the changes that have gone in to see what to focus on
[18:29] <davmor2> or change hardy to intrepid
[18:29] <sbeattie> davmor2: intending for 8.04.1 images.
[18:29] <heno> we also talked about copying the test cases over to .../LTS/...
[18:29] <sbeattie> LaserJock: not yet, that's something I else I want/need to generate
[18:29] <heno> so we can keep them as they are while updating for Intrepid
[18:30] <heno> i.e. fork them
[18:30] <davmor2> sbeattie: yes change the path for where the script looks for the image
[18:30] <sbeattie> davmor2: thanks, good to know.
[18:30] <LaserJock> sbeattie: perhaps you can use pitti's script to extract out the bug #s for everything in hardy-updates?
[18:31] <davmor2> sbeattie: as long as there is still a current it should be fine :)
[18:31] <LaserJock> sbeattie: filtering out Universe that should give you quite a lot of info still
[18:31] <sbeattie> LaserJock: that's a possiiblity.
[18:31] <sbeattie> LaserJock: you interested and available to help out with that?
[18:31] <heno> That should only affect Ubuntu though as Kubuntu is not LTS FOR 8.04
[18:31] <sbeattie> ("no" is a perfectly valid answer)
[18:32] <LaserJock> sbeattie: some at least yeah. I'm interested in the answer for Universe as well
[18:32] <sbeattie> LaserJock: that's what I suspected
[18:32] <sbeattie> action: sbeattie (primarily) and laserjock to generate a list of fixes going in to 8.04.1
[18:32] <sbeattie> ACTION: sbeattie (primarily) and laserjock to generate a list of fixes going in to 8.04.1
[18:33]  * sbeattie hrm
[18:33] <cody-somerville> sbeattie, LaserJock: Make sure not to forget Xubuntu :)
[18:33] <heno> buggy bot
[18:33] <stgraber> I guess heno needs to do that, and it's [ACTION]
[18:33] <LaserJock> it doesn't like you. perhaps you need to feed it more bot snacks
[18:34] <LaserJock> cody-somerville: make sure to ping us about that, but yeah, we'll have to keep that in mind :/
[18:34] <heno> [ACTION]: sbeattie (primarily) and LaserJock to generate a list of fixes going in to 8.04.1
[18:34] <MootBot> ACTION received: : sbeattie (primarily) and LaserJock to generate a list of fixes going in to 8.04.1
[18:34] <sbeattie> heno what was that about kubuntu?
[18:34] <LaserJock> cody-somerville: maybe we can look for SRUs in packages in the Xubuntu Hardy seed?
[18:34] <cody-somerville> [ACTION] cody-somerville to liaison with LaserJock regarding fixes going in to 8.04.1 for Xubuntu specific packages.
[18:35]  * cody-somerville tried.
[18:35] <heno> sbeattie: because Kubuntu is staying on KDE 3.5 (+the 4.0 remix), Kubuntu isn't LTS for 8.04
[18:35] <heno> so we don't need to keep copies of the Kubuntu test cases around for 3/5 years
[18:35] <sbeattie> ah, got it.
[18:36] <heno> we are respinning the CDs now because of the ssl issues AFAIU
[18:36] <sbeattie> yes, branching the testcases would be good.
[18:36] <heno> which we don't expect to repeat :)
[18:36]  * slangasek nods
[18:36] <heno> [TOPIC]: Spec status
[18:36] <MootBot> New Topic: : Spec status
[18:37] <sbeattie> heno: one sec
[18:37] <heno> ok
[18:37] <sbeattie> slangasek: are you okay if we push for more widespread testing of the alsa update?
[18:37] <sbeattie> i.e. blog/forum announcements?
[18:38] <slangasek> I'm somewhat concerned that this would flood us with low-quality feedback while we're still trying to sort out the meaning of bugs like #240337
[18:38] <sbeattie> That one does seem to be missing hardware info
[18:40] <heno> too much testing of -proposed seem like a bit of a luxury problem
[18:40] <heno> we got a reasonable response after I blogged, but not a flood
[18:41] <sbeattie> slangasek: we could time it for a couple days out, to give Luke time to sort out that particular issue if possible.
[18:41] <persia> Luke doesn't have HW to replicate the issues with the bug
[18:43] <slangasek> persia: what hardware is that? the bug doesn't seem to say
[18:43] <heno> what HW is it, and can we get it to him?
[18:44] <persia> slangasek: Perhaps I'm confused then.  He was previously saying that he was having trouble replicating some of the pulse issues that might be related to the ALSA mismatch, as his HW worked.
[18:45] <persia> Nevermind.  I've read the bug backwards.  That's a 1.0.16 bug.  Sorry.
[18:45] <slangasek> ok :)
[18:46] <heno> ok, shall we move to specs?
[18:46] <sbeattie> that's fine.
[18:47] <heno> Thanks everyone for polishing off the specs
[18:47] <heno> they are now all in good shape and Approved
[18:47] <heno> (appart from a fw that are not started ...)
[18:48] <heno> and I need to re-read the mobile one
[18:48] <heno> cgregan: thanks for updating, looks good at a glance
[18:48] <cgregan> heno: I completed the updates we spoke about.
[18:48] <cgregan> :-)
[18:49] <cody-somerville> Is there anybody that can help me with this bug? It is rather important.
[18:49] <cody-somerville> https://bugs.edge.launchpad.net/ubuntu/+source/dbus/+bug/232364
[18:49] <heno> I also want to add one about automated CD testing and one about QAs role in advising on release status
[18:49] <cody-somerville> It should really be fixed for the point release if at all possible
[18:49] <cody-somerville> Oops, I guess I interjected there.
[18:50] <heno> cody-somerville: that's ok, can you bring it to #u-bugs or #u-testing afterwards?
[18:50]  * cody-somerville nods.
[18:51] <heno> bdmurray: I looked at the teams in LP as we talked about for the categories on the package info pages but found the mapping quite poor, so I wen't with a hand-crafted stucture loosely based on team interest
[18:52] <heno> we may need to refine that as we go, but we shouln't block on it
[18:52] <bdmurray> heno: I thought that we should improve the mapping in Launchpad
[18:53] <heno> bdmurray: right, wecan still go that route, but ATM it's quite inconsistent how teams relate to packages
[18:54] <bdmurray> okay, sounds good
[18:54] <heno> and if we make changes across the board it will affect the bug mail people get I guess
[18:55] <heno> I still like that approach but it was starting to look like a major blocker
[18:56] <heno> any other comments on specs? if not let's revisit them in 2 weeks
[18:56] <davmor2> maybe leave it till it's safe to play about with it and formalise a plan of attack and lay it out properly then?
[18:56] <LaserJock> heno: what spec were you just discussing?
[18:56] <heno> davmor2: I'd rather have the pages up sooner so we can get use from them
[18:57] <heno> even if the structure is not 'perfect'
[18:57] <heno> LaserJock: https://blueprints.launchpad.net/ubuntu/+spec/package-status-pages
[18:58] <davmor2> heno: sorry not well explained.  Keep things as they are now then when it is safe to swap stuff around re-think the layout then is what I mean :)
[18:58] <heno> davmor2: ok, then I agree :)
[18:58] <heno> any other topics for the meeting?
[18:58] <heno> (2 minute ones :) )
[18:59] <davmor2> one minute your clock is slow ;)
[18:59] <pedro_> not from me
[18:59] <LaserJock> heno: why would those status pages not be done by Launchpad, and for every package?
[19:00] <heno> LaserJock: we basically have those pages already for each package in LP ;)
[19:00] <LaserJock> virtually all the data is from Launchpad it looks like (except maybe popcon, but that probably should be in Launchpad as well ;-) )
[19:00] <heno> this will be more team focused, collecting packages together
[19:01] <LaserJock> heno: and wouldn't that go into a teams package report on Launchpad?
[19:01]  * LaserJock is playing a bit of devil's advocate, but is curious
[19:01] <heno> we are prototyping this now but the functionality should probably be implemented in LP later, I agree
[19:02] <LaserJock> ok
[19:02] <bdmurray> That's part of the motivation for having the assoication btwn teams and packages exist in lp
[19:02] <heno> LaserJock: I agree, we are just trying to move it along
[19:03] <davmor2> make assigning bugs easy too I guess :)
[19:03] <heno> bdmurray: right, I'd be happy to get a second opinion on the feasibility of doing that now
[19:03] <bdmurray> heno: I'll look into it with one of the teams
[19:04] <heno> bdmurray: I only had a brief look and don't know the dusty corners of LP as well as you do :)
[19:04] <heno> bdmurray: great, thanks
[19:04] <heno> ok, thanks all!
[19:04] <heno> #endmeeting
[19:04] <MootBot> Meeting finished at 13:07.
[19:04] <davmor2> bye !
[19:04] <pedro_> thanks
[19:05] <sbeattie> thanks!
[19:05] <stgraber> thanks
[19:25]  * cody-somerville stretches.
[19:30] <zoredache> !time
[20:21] <TheSheep> @now
[20:37] <cody-somerville> hmm...
[20:37]  * cody-somerville pokes ubottu 
[20:40] <TheSheep> cody-somerville: we still have 20 minutes
[20:40] <cody-somerville> :)
[20:42] <pimanx> @schedule
[20:50] <charlie-tca> Just waiting for the Xubuntu community meeting
[20:51] <Moe> well, we've just been waiting for you obviously
[20:52] <cody-somerville> :)
[20:52] <charlie-tca> glad to hear it
[20:53] <cody-somerville> For those who haven't had a chance to review it yet, the draft can be found at https://wiki.ubuntu.com/Xubuntu/Specifications/Intrepid/StrategyDocument
[20:59]  * cody-somerville stretches.
[21:01]  * cody-somerville cheers.
[21:01] <cody-somerville> Hello Folks!
[21:01] <cody-somerville> \o_
[21:02] <cody-somerville> I'm just finishing up at work
[21:02] <charlie-tca> hello
[21:02] <charlie-tca> I'm retired, but just starting work
[21:03] <cody-somerville> charlie-tca, :)
[21:04] <Moe> I'll be listening mostly
[21:04] <cody-somerville> This is a follow up meeting to the very successful Xubuntu community meeting we had not too long ago.
[21:05] <cody-somerville> With the help of Jono Bacon, the Ubuntu Community Manager, we as a community were able to come together to find consensus on several key issues.
[21:06] <cody-somerville> The most important accomplishment we made was agreeing on an initial mission statement
[21:07] <Moe> uhu .. there goes the bot
[21:08] <TheSheep> we don't need no stinkin bot ;)
[21:08] <cody-somerville> I'm also very grateful that I was tasked with the responsibility of forging forward as the newly appointed Xubuntu Team Leader. My initial mandate being to develop a strategy document that would provide a solid foundation for the Xubuntu project to grow and mature.
[21:08] <Moe> Guess the bot didn't think so
[21:09] <cody-somerville> The mission statement which was agreed upon is as follows:
[21:10] <cody-somerville> Xubuntu will provide (The goal of Xubuntu is to produce) an easy to use distribution, based on Ubuntu, using Xfce as the graphical desktop, with a focus on integration, usability and performance, with a particular focus on low memory footprint. The integration in Xubuntu is at a configuration level, a toolkit level, and matching the underlying technology beneath the desktop in Ubuntu. Xubuntu will be built and developed auto
[21:10] <cody-somerville> nomously as part of the wider Ubuntu community, based around the ideals and values of Ubuntu.
[21:12] <cody-somerville> For a project to have a useful vision and strategy, it must have a target audience or group. The target audience (or group) for Xubuntu is users who are interested in having a modestly light weight, slim, fast desktop experience while retaining the usability and functionality that is required to provide an easy to use desktop environment.
[21:12]  * TheSheep has a deja vu
[21:13] <cody-somerville> Now, before I bore everyone with fluffy talk, I think it is important to dig right in
[21:13] <cody-somerville> I'
[21:13] <cody-somerville> We will use a three tier system that defines our foci and provides a transparent, agnostic framework that can be applied to dispute resolution, package selection, policy, and our decision making processes.
[21:14] <cody-somerville> This is a unique feature to the Xubuntu community which I feel will enable us to make fluid strides towards achieving objectives.
[21:14] <cody-somerville> Focus 1: Integration
[21:15] <cody-somerville> It is important for us to provide an integrated desktop as it is a critical component to being a useful desktop, a usable desktop, and an effective desktop. Without integration, the Xubuntu desktop will be rough and unpolished which is unappealing to our end-users. We will provide an integrated desktop by selecting packages that work well with each other and applying patches (aka "glue") to further improve the situation.
[21:15] <cody-somerville> Success is measured by considering the progress made during a release cycle towards related specifications and user feedback. In the future, more comprehensive metrics will be developed.
[21:15] <cody-somerville> Focus 2: Usability
[21:16] <cody-somerville> We want Xubuntu to be usable. By this, not only do we mean we want Xubuntu to be easy to use but also accessible and localized to enable users who face impairments and those wishing to work in their own tongue. To accomplish this, we'll strongly consider the usability and accessibility of an application when deciding on package selection, invest in contributing to upstream usability and localization efforts, and pulling on t
[21:16] <cody-somerville> alent from our community to provide interface usability analysis.
[21:16] <cody-somerville> Success in providing an accessible desktop can be measured through testing (including automated) and user feedback while localization will be measured by looking at the percentage of the desktop that is translated. To measure how easy to use Xubuntu is, we'll employ test cases and draw on the community talent to provide professional grade analysis.
[21:16] <cody-somerville> Focus 3: Performance
[21:17] <cody-somerville> Being lightweight, slim, and fast are all words that have been used to describe and market Xubuntu. However, over the last few releases we've noticed that not only does Xubuntu pale in comparison to some of the other Xfce4 distributions but we've also been putting on even more weight and bulk. Although it is not Xubuntu's goal nor target to provide a desktop environment which will run on the most minimal of systems, it is Xu
[21:17] <cody-somerville> buntu's goal to provide a desktop that is modest and can run with minimal problems on machines that have aged a few years.
[21:17] <cody-somerville> Now, this part is important
[21:17] <cody-somerville> The initial target will be 128mbs-192mbs of RAM (with appropriate swap space available) and 333Mhz-400Mhz CPU. The target for a release will be evaluated at the beginning of each release cycle and updated as required.
[21:17] <Moe> 400Mhz?
[21:17] <Moe> Can I come in there?
[21:18] <cody-somerville> Dare I ask where?
[21:18] <Moe> I don't want to interrupt if this isn't the right moment
[21:18] <pygi> cody-somerville, I believe he wants to say something
[21:18] <Moe> well, I don't think 400Mhz is a pretty realistic projection
[21:18] <cody-somerville> Okay.
[21:18] <cody-somerville> What do you feel would be more realistic?
[21:18] <Odd-rationale> 600Mhz ?
[21:19] <Moe> At least
[21:19] <Moe> I mean .. of course, you MIGHT just be able to get it to run on 400Mhz
[21:19]  * TheSheep used xubuntu dapper on a 200Mhz box, it was possible...
[21:19] <cody-somerville> I ran Xubuntu on 333mhz for several years.
[21:19] <charlie-tca> If I may, you can run all the versions so far on 400 Mhz
[21:19] <Moe> But you just told us about Xubuntu's strive for usability
[21:19] <Moe> And its hardly going to be of much use on a 400Mhz processor
[21:20] <Moe> From what I can tell
[21:20]  * pygi notes that especially burning higher capacity disks require more CPU ...
[21:20] <charlie-tca> two of my 4 systems I use daily are 400Mhz
[21:20] <TheSheep> it all depends on the use case
[21:20] <cody-somerville> Thank you for bringing that up Moe.
[21:20] <cody-somerville> I think you've made an excellent point
[21:20] <TheSheep> some use cases will require faster cpus
[21:20] <Moe> Oh your welcome .. I just thought I'd voice my opionion on that .. please go on
[21:20] <TheSheep> playing dvd movies...
[21:21] <cody-somerville> I think that Xubuntu should aim for a range
[21:21] <TheSheep> cody-somerville: about that, you cannot target a range, you can target several targets, but not a range...
[21:21] <pygi> the thing is ... the apps that you ship must be usable under most use cases
[21:22] <cody-somerville> pygi, Most appear to be (except maybe Firefox)
[21:22] <Moe> Whats Xubuntu shipping as its default email client again?
[21:22] <pygi> cody-somerville, ship Midori then?
[21:22] <Odd-rationale> ff3b5 was slow loading on to my 500-600Mhz. i don't know about yours...
[21:22] <cody-somerville> Moe, Thunderbird.
[21:22] <TheSheep> midori is not really stable, is it?
[21:23] <Moe> Okay, what applies to firefox applies to thunderbird as well
[21:23] <Odd-rationale> TheSheep: not quite...
[21:23] <Moe> Keep that in mind
[21:23] <pygi> TheSheep, it hasnt crashed even once on me, while ff has millions of times
[21:23] <cody-somerville> I think it is important that Xubuntu does not exclusively target users with low, modest, or high powered machines but instead targets the entire spectrum with a strong focus on enabling lower end machines. Xubuntu's extra responsiveness and speed, among other positive traits, can be appreciated by all users regardless of their hardware - no?
[21:23] <Odd-rationale> what about epiphany-webkit, when it is stable?
[21:23] <pygi> Odd-rationale, also seems even better, as it is supported by gnome project (6 months release cycle)
[21:24] <TheSheep> Odd-rationale: that;s a decission to make once we have the strategy defined
[21:24] <Moe> cody-somerville: I second that
[21:24] <Odd-rationale> k
[21:24] <cody-somerville> So, although the experience won't be super stellar on a 333mhz we aren't aiming for that either
[21:25] <Moe> We weren't talking about stellar performance .. we were talking about Xubuntu being usable at 333Mhz ;-)
[21:25] <cody-somerville> We're simply looking to enable that machine to an agreed and achievable level of usefulness.
[21:25] <cody-somerville> Well, as someone who has used Xubuntu on a 333mhz for a number of years I certainly appreciated having Xubuntu around :)
[21:25] <TheSheep> cody-somerville: it's just my opinion, but shouldn't we have several well-defined targets, instead of that range? For example, have a separate "low-spec user, low expectations" user and another "I want everythng" one?
[21:25] <charlie-tca> I think it is usable, with the exception of FF3
[21:25]  * cody-somerville nods at charlie-tca.
[21:25] <cody-somerville> TheSheep, Thats an excellent idea, IMHO.
[21:26] <Moe> However, I'll rest my case for now .. I haven't run Xubuntu on a mere 333Mhz yet .. so I'm shooting in the dark here (although, my assumptions are founded on experience)
[21:26] <TheSheep> so we have "low-end user wants to do this, this and that, but doesn't care about this, this and that"
[21:26] <Moe> TheSheep: Xubuntu Home Basic and Xubuntu Ultimate?
[21:26]  * Moe chuckles
[21:26]  * pygi burns Moe 
[21:26] <Moe> Sorry, couldn't resist
[21:27] <TheSheep> Moe: no, one install, just two use scenarios
[21:27] <Moe> right right .. I know what you mean .. just ignore my blabber
[21:28] <charlie-tca> Granted, I use what I need when running the low-speed cpus, but can't you run all the programs in a faster machine?
[21:29] <cody-somerville> Ok. I endorse TheSheep's idea about instead of having a range, having several well defined targets each with well defined expectations.
[21:29] <cody-somerville> Any other points/comments about any of the three focuses? :)
[21:30] <TheSheep> cody-somerville: disk space for the "performance" part
[21:30] <TheSheep> or rather "lightweightness"
[21:31] <TheSheep> it's getting important with those flash-based cheap laptops around
[21:31] <Odd-rationale>  
[21:31] <Odd-rationale> oops...
[21:31]  * pygi just notes epiphany-webkit/midori + syphleed-claws (or whatever the name is) would work much better then tb + ff
[21:31] <Odd-rationale> pygi: claws mail
[21:31] <cody-somerville> Well, one change I made today is modifying our seeds to allow for individuals to uninstall packages they rather not have without removing xubuntu-desktop along with it
[21:31] <cody-somerville> :)
[21:31] <Odd-rationale> cool!
[21:32] <Odd-rationale> i was wondering about that...
[21:32] <charlie-tca> Great!
[21:32] <pygi> Odd-rationale, yea, but syphleed-claws is more bleeding edge :)
[21:32] <cody-somerville> Now for those of you following along in the specification, you know whats next.
[21:32] <Odd-rationale> pygi: oh, ok. i thought claws mail was the "better". could have gotten confused...
[21:32] <highvoltage> howdy!
[21:33] <cody-somerville> Heya highvoltage :)
[21:33] <charlie-tca> pygi: syphleed-claws is replaced by claws-mail; sylpheed is also good without the bells and whistles
[21:33] <pygi> charlie-tca, ah, that, yes :p
[21:33] <pygi> Odd-rationale, you were right, sorry :)
[21:33]  * cody-somerville introduces "(Unofficial) Focus 4: Community"
[21:33] <highvoltage> hey cody!
[21:33] <pygi> highvoltage, long time no see ;)
[21:33] <cody-somerville> Although not an official element of the Xubuntu Three Tier focus (which is limited in scope to technical considerations), community *is* most certainly a focus and priority within the Xubuntu project. Xubuntu is community driven meaning that it is developed, maintained, and supported by members of the Xubuntu community. For Xubuntu to be a healthy and successful project, it must have a healthy and successful community. Xubun
[21:33] <cody-somerville> tu, as a project, will aim to be composed of a vibrant, active and energized community and will attempt to accomplish this by being proactive in its development of said community. Xubuntu will host bug days, packaging jams, and other public events specifically targeted to raising awareness and interest in the Xubuntu project.
[21:33] <highvoltage> pygi: heh, yes. I bet uni is keeping you very busy
[21:34] <pygi> highvoltage, yea, and mucho nice new stuff :)
[21:34] <TheSheep> charlie-tca, pygi: these are really specific decissions that will be made according to this strategy cody is trying to make :)
[21:34] <highvoltage> cody-somerville: where can I see the three tier focus?
[21:34] <TheSheep> highvoltage: https://wiki.ubuntu.com/Xubuntu/Specifications/Intrepid/StrategyDocument
[21:34] <cody-somerville> highvoltage, https://wiki.ubuntu.com/Xubuntu/Specifications/Intrepid/StrategyDocument
[21:34] <highvoltage> ah right
[21:35] <cody-somerville> Included in my endeavour to support the growth of the Xubuntu community is my interest in developing stronger relationships with upstream - ie. Debian and Xfce4
[21:35] <cody-somerville> I'm really excited to see a number of Xfce4 developers/contributors with us this for this meeting - it certainly means a lot to me :)
[21:36] <highvoltage> :)
[21:37] <cody-somerville> I thought that some upstream developers have expressed discontent with how certain situations have been handled in the past. However, I want Xubuntu to be well known as a constructive and active contributor to the free software ecosystem.
[21:39] <cody-somerville> Being a good "neighbour" is important to Xubuntu and important to me :)
[21:40] <Moe> Thank you .. Xfce appreciates your concerns and welcomes an contributions
[21:40] <Moe> *any
[21:40] <cody-somerville> Moe, Splendid! :)
[21:40] <Moe> Especially with our new, upcoming release
[21:40]  * pygi casts ++ on what Moe said :)
[21:41] <cody-somerville> Moe, If there is anything we can do to help then please feel free to make it known :)
[21:41] <Moe> Incase it hasn't been noticed yet .. Xfce has put out a roadmap and milestone definition for Xfce 4.6
[21:41]  * cody-somerville nods.
[21:41] <cody-somerville> Very exciting times for Xfce I think :)
[21:41] <Moe> The next alpha release is scheduled for the 29th this month
[21:42] <highvoltage> wow, that's quite cool
[21:42] <Moe> Anything thats on the roadmap page and isn't done for 4.6 yet needs to be addressed
[21:42] <Moe> First and foremost, two compoments that really need attention right now are the menu editor (which hasn't even been started yet) and the mixer
[21:42] <daigorobr> roadmap url is...?
[21:42] <cody-somerville> I imagine it would be helpful for us to upload those snapshots to our development version (as they'll receive extensive testing if we do so).
[21:43] <cody-somerville> Yes?
[21:43] <Moe> http://wiki.xfce.org/roadmap_to_46
[21:43] <daigorobr> Thanks
[21:43] <Moe> http://wiki.xfce.org/milestones_to_46
[21:43] <Moe> cody-somerville: Absolutely
[21:43] <Moe> Beware though, the alpha release is by no means ready for serious production environments .. or even home computers
[21:43] <mr_pouit> (if we have testers and bug triagers in xubuntu, and that's not the case actually)
[21:43] <Moe> We're in the process of integrating the configuration architecture
[21:44] <cody-somerville> mr_pouit, You may not know this but Canonical actually does test Xubuntu ;]
[21:44] <Moe> Most of the backend code has been written .. and even some of the frontends have been migrated already
[21:44]  * cody-somerville nods @ Moe.
[21:44] <jeromeg> cody-somerville: but they do not forward the bugs
[21:44] <mr_pouit> cody-somerville: that's why we have to do these ~13 srus?
[21:44] <jeromeg> and no one does since I lived
[21:44] <Moe> But anything apart from the core components is still lacking behind (as it is not required to be ready for nor ship with the alpha release)
[21:44] <cody-somerville> jeromeg, mr_pouit
[21:45] <cody-somerville> Moe, Is there any component in particular that individuals who are not familiar with developing Xfce4 would be able to jump in easily?
[21:45]  * pygi votes for xfburn
[21:45] <jeromeg> cody-somerville: yes ?
[21:45] <jeromeg> + 1 for xfburn
[21:45] <pygi> cody-somerville, we're willing to provide mentorship for whatever is needed anyway :)
[21:46] <jeromeg> pygi and david are very welcoming mentors
[21:46] <Moe> well, the menu editor is the best way to start of actually .. as it hasn't been touched yet
[21:47] <Moe> libxfce4menu (written by Jannis Pohlmann) is a pretty good library implementing the freedesktop menu spec
[21:47] <Moe> I'm sure writing a menu editor would help him sort out the few remaining bugs
[21:47] <Moe> So thats a place to start
[21:47] <gpocentek> is there anyone in the xubuntu team who has already touch GTK apps?
[21:47]  * cody-somerville me.
[21:47] <gpocentek> I mean, *really*, not one liner patches
[21:48] <gpocentek> dealing with gobject and fun like that?
[21:48]  * cody-somerville sorta has.
[21:48]  * cody-somerville notes that he just a call from a client, please continue discussion. :)
[21:49] <gpocentek> bugs are triaged once per month, and the plan is now to develop apps?
[21:49] <cody-somerville> One second, and I'll respond to that
[21:49] <pygi> we actually got some contributions from a folk who's been playing with C for a few weeks only
[21:49] <jeromeg> pygi: hello ;)
[21:49] <Moe> Of course .. hunting down bugs and/or hunting developers with bugs already filed with the bugtracker is a worthwhile job as well
[21:50] <pygi> and he learned basics of GTK+ and gobject enough to contribute a few enchantments here and there
[21:50] <pygi> jeromeg, greetings ^_^
[21:50] <pygi> so it's really not that hard
[21:50] <gpocentek> that's one person...
[21:51] <jeromeg> pygi: and it's me ;)
[21:51] <Moe> Apart from that, the roadmap is full of suggestions and/or steps needed to be taken before 4.6 can be released
[21:51] <pygi> well, yea, I'm just saying that everyone is more then welcome to jump in, say what they wanna work on, and we'll be glad to mentor
[21:51] <mr_pouit> and this person isn't in the xubuntu team ^_~
[21:51] <pygi> mr_pouit, that's true tho :)
[21:52] <mr_pouit> once upon a time he did triage all xubuntu bugs alone ;P
[21:52] <gpocentek> what I meant is that there's no resources ATM to handle both work on the distro and coding (IMO)
[21:52] <jeromeg> gpocentek: well, there are no resources at all
[21:52] <jeromeg> except if people step in
[21:53] <jeromeg> the packages are managed by mr_pouit and gpocentek which are not in the xubuntu team
[21:53] <jeromeg> who are not, sorry
[21:53] <Moe> I'll need to head out now .. feel free to subscribe to the xfce mailinglists if you want to jump in .. or even drop me an email directly via moe@xfce.org
[21:53] <daigorobr> I really think that the work should be divided in classes, even if there isn't enough ppl. And then priorities set.
[21:53] <Moe> Way to go Xubuntu
[21:53] <Moe> later
[21:53] <jeromeg> see you Moe
[21:54] <TheSheep> daigorobr: that makes it even harder to do the work. it's not fun to do something you are told to do
[21:54] <daigorobr> And just then you ppl should start recruiting ppl.
[21:54] <daigorobr> TheSheep: Fact.
[21:54] <daigorobr> But I take myself as an example.
[21:54] <daigorobr> I am passionate about Ubuntu, and passionate about low end machines. Xubuntu is my niche.
[21:55] <daigorobr> But I also have my day job, that takes lots of energy.
[21:55] <daigorobr> I wanted to contribute. But how? Where I find "job offers" for the team?
[21:55] <daigorobr> I can't enlist for programming and triaging bugs and this and that.
[21:56] <TheSheep> it would be nice if you could just pick somehting and work on it when you have time and energy, and not have it wasted even if you don't finish
[21:56] <jeromeg> daigorobr: triaging bugs is actually quite hard
[21:56] <daigorobr> And I bet there is a lot of ppl that wanted to contribute but don't have enough time to commit fully.
[21:56] <daigorobr> I know.
[21:56] <daigorobr> That's what I say, jeromeg.
[21:56] <daigorobr> The commitment can be extenuating.
[21:56] <jeromeg> you need to go to the Launchpad page of the application
[21:56] <jeromeg> and look if there is an open bug
[21:57] <jeromeg> then read the bug summary
[21:57] <daigorobr> But I bet I interrupted you people in something more important.
[21:58] <daigorobr> jeromeg: I know it's hard and important. Been there already.
[21:58] <cody-somerville> Sorry about that, I had a client on the phone :)
[21:58]  * cody-somerville reads up.
[21:58] <jeromeg> daigorobr: I was jocking, it's not hard
[21:58] <jeromeg> daigorobr: it's just time consuming
[21:58] <jeromeg> so no one wants to do it :)
[21:58] <daigorobr> jermoeg: Exactly.
[21:58] <TheSheep> jeromeg: I think it is very hard on average
[21:59] <daigorobr> jeromeg: Time consuming means hard for me.
[21:59] <jeromeg> TheSheep: the only difficult thing is to guess if it's caused by one of our sucking patches or if ti's an upstream issue
[21:59] <daigorobr> Programming is fun. Bureaucracy is hard.
[21:59] <cody-somerville> Okay, before this meeting gets derailed lets bring things back on track. :)
[21:59] <TheSheep> jeromeg: I only did it several times, but you need pretty good knowledge about how applications work internally to guess which compaonent is broken and whether it's not just a bad configuration
[21:59] <daigorobr> cody-somerville: Agreed.
[22:00] <cody-somerville> 1. Gpocentrek and Jeromeg express concern that because there is not enough people to staff Xubuntu how could we possible commit to contributing directly to Xfce4?
[22:00] <cody-somerville> The simple answer is that those concerns are very valid and no amount of wishing will change that
[22:00] <cody-somerville> So, no, I'm not suggesting Xubuntu pledge code contributions, etc. etc.
[22:01] <cody-somerville> We obviously have to live within our means to sustain ourselves with the limited resources we have.
[22:01] <cody-somerville> However, that certainly isn't going to stop me from hacking away on interesting problems or bugs that are bothering me and contributing those patches back upstream :)
[22:02] <jeromeg> mmm
[22:02] <cody-somerville> People's interest commitment, and activity level are constantly changing - including my own.
[22:03] <daigorobr> cody-somerville: but not as a xubuntu team motto, you mean. just as a fun thing to do.
[22:03] <jeromeg> sure, but the problem is that the basics have to be done
[22:03] <daigorobr> (forgive me my english)
[22:03] <cody-somerville> I've been rather busy with work but this week I've actually devoted quite a large amount of time in my attempt to fix bug #232364
[22:03] <cody-somerville> jeromeg, agreed.
[22:03] <TheSheep> cody-somerville: that's my favorite one
[22:04] <TheSheep> cody-somerville: we can compare notes one day...
[22:04] <jeromeg> if bugs are not triaged and forwarded, there is no point in shipping the alpha releases of xfce
[22:04] <cody-somerville> jeromeg, Agreed.
[22:05] <cody-somerville> jeromeg, However, bugs will be triaged and will be forwarded - I'm confident of it
[22:05] <jeromeg> the holy spirit will do it ?
[22:06] <jeromeg> and if by triaged you mean mr_pouit and gpocentek when the queue too long, this is not enough
[22:06] <cody-somerville> I don't mean that, jeromeg.
[22:06] <cody-somerville> jeromeg, gpocentek and mr_pouit are not the only ones helping with bugs and packaging.
[22:07] <TheSheep> I think there are a lot of people who would help if they were shown how
[22:07] <cody-somerville> jeromeg, Infact, I expect the number of contributors will increase quite noticeably over this release cycle as long as we can all pull together and show people how incredibly awesome Xubuntu is :)
[22:07] <charlie-tca> TheSheep: I agree with that. It's finding how to help and "who can teach me" that seems difficult
[22:08] <cody-somerville> TheSheep, Agreed.
[22:08] <cody-somerville> It is kind of the chicken and the egg problem, no?
[22:08] <TheSheep> yes
[22:08] <gpocentek> how did we get involved? I mean, we didn't wait for people to show us...
[22:08] <cody-somerville> This is why I'm planning to take advantage of some of the creative ideas we've seen generated here in the Ubuntu community like bug days
[22:09] <TheSheep> which is kind of bringing hope, as it's possible to get a snowball effect...
[22:09] <cody-somerville> gpocentek, Nope but you didn't just become the top contributor over night, right?
[22:09] <jeromeg> nah, it took him two ;)
[22:09] <mr_pouit> (and "chicken and egg" problem would mean that if there's nobody working on xfce in ubuntu, that's because it sucks right now?
[22:09] <mr_pouit> )
[22:09] <gpocentek> cody-somerville: I never said that, but there's a huge step between top-contributor and nothing
[22:09] <cody-somerville> gpocentek, Agreed.
[22:10] <gpocentek> and i've never been top contributor :)
[22:10] <charlie-tca> Can't we publish the wiki "how to help xubuntu" page periodically?
[22:10] <cody-somerville> Lots of people want to be involved they just don't want to *get* involved.
[22:10] <cody-somerville> It seems like we're getting offtopic again :)
[22:10] <jeromeg> triaging is really not hard
[22:10] <cody-somerville> However, I'm glad we brought this up.
[22:10] <jeromeg> https://bugs.launchpad.net/ubuntu/+source/xfce4-panel
[22:10] <jeromeg> just grab a bug here
[22:10] <cody-somerville> Because it is something I'm very passionate about seeing improved.
[22:10] <jeromeg> try to confirm it
[22:10] <jeromeg> look at the backtrace to see if it's not full of ???????
[22:11] <jeromeg> once you have a backtrace without ???????? from the user
[22:11] <jeromeg> forward the bug to the xfce bugzilla
[22:11] <jeromeg> if it's a whishlist, forward it directly
[22:11] <jeromeg> always check if it has not been reported upstream before
[22:12] <cody-somerville> jeromeg, Maybe you'd like to get together sometime and write up a guide/blog post with me ( mr_pouit and gpocentek and whoever else of course invited as well ) to write up a Xubuntu specific guide?
[22:13] <cody-somerville> jeromeg, We wouldn't repeat stuff that is already on the wiki
[22:13] <cody-somerville> jeromeg, But I imagine you have some wisdom to share about how to best deal with upstream and such
[22:13] <gpocentek> a xubuntu specific guide?
[22:13] <cody-somerville> gpocentek, or an "insert" to the normal one ;]
[22:13] <jeromeg> cody-somerville: the rules are the same for every upstream project
[22:13] <jeromeg> I don't think we need a guide for xubuntu
[22:14] <mr_pouit> (to do bug triaging, the ubuntu bugsquad wiki pages should be ok ;)
[22:14] <jeromeg> http://bugzilla.xfce.org/
[22:14] <cody-somerville> no no, you guys misunderstand me :)
[22:14] <jeromeg> to report bugs
[22:14] <cody-somerville> I don't mean we rewrite whats already there
[22:14] <cody-somerville> but I imagine having a page with Xubuntu specific info would be helpful for people getting involved in bug triaging Xubuntu.
[22:15] <cody-somerville> I'll elaborate more on it later on the mailing list.
[22:15] <jeromeg> the very positive step you could take
[22:15] <jeromeg> is to clean our patches
[22:15] <jeromeg> and to move them uptream
[22:16] <cody-somerville> jeromeg, Agreed.
[22:16] <jeromeg> or drop them if they can't be emrged
[22:16] <jeromeg> this delta is really a pain
[22:16] <gpocentek> (+1)
[22:16]  * cody-somerville nods.
[22:17] <cody-somerville> So, before we move on was there any items of consensus that was reached and I've missed besides the performance targets?
[22:17] <cody-somerville> (and besides that moving patches upstream is important)
[22:18] <charlie-tca> I don't think so?
[22:19] <cody-somerville> Ok, we're behind schedule so I'm going to list off the remaining topics and could people please list a small number of them that you feel needs to be discussed.
[22:22] <cody-somerville> Xubuntu Team Structures, Xubuntu Governance, Dispute Resolution, Communication, Xubuntu development coordination, release cycle, Xubuntu Seeds & package composition, Development dispute resolution, what-ever-we-have-and-would-like-to-get-off-our-chest, other.
[22:22] <cody-somerville> and I also forgot "instigating growth" (how can we grow the community?).
[22:23] <jeromeg> I think that as long as the community is reduced we should keep with the basis
[22:24] <jeromeg> triage bugs, fix bugs, integrate new upstream releases
[22:24] <charlie-tca> Xubuntu documentors - will they become a separate entity from Ubuntu-documentation team?
[22:24]  * cody-somerville nods.
[22:25] <Odd-rationale> i gtg. Thanks cody-somerville! good bye everyone!
[22:25] <cody-somerville> I'd like to discuss bug triage as well along with Xubuntu team structure, and Xubuntu seeds & composition.
[22:25] <daigorobr> I'm most interested in seeds and composition
[22:25]  * cody-somerville nods.
[22:26] <cody-somerville> gpocentek, mr_pouit ?
[22:26] <gpocentek> what do you want to discuss?
[22:26] <gpocentek> about bug triaging
[22:27]  * sectech is curious about the triaging
[22:28] <cody-somerville> gpocentek, Well, one of the major complaints it seems from jeromeg and yourself is the lack of bug triage that is taking place.
[22:28] <cody-somerville> I'd be interested in discussing how we can improve the situation.
[22:28] <jeromeg> cody-somerville: you can triage bugs
[22:28] <gpocentek> cody-somerville: the problem is always the same, we are 3 contributors
[22:28] <gpocentek> that's it
[22:28] <cody-somerville> I also think it would be helpful for us to agree on a way we denote a bug "release critical".
[22:29] <cody-somerville> jeromeg, hmm?
[22:29] <sectech> Now that I come to think of it, I haven't run across a specific xubuntu bug while triaging.
[22:29] <cody-somerville> sectech, Actually, you have.
[22:29] <cody-somerville> sectech, Lionel marked a bug you had triaged as a duplicate of another bug the other day.
[22:29] <cody-somerville> ;]
[22:29] <cody-somerville> gpocentek, Well, lets see how we can increase that number.
[22:29] <sectech> Ahh... I need to go through my email again it seems
[22:30] <cody-somerville> At one time, we had atleast 4-6 people doing bug triage IIRC.
[22:30] <jeromeg> cody-somerville: huh ?
[22:30] <jeromeg> 4 to 6 ?
[22:30] <daigorobr> Hrm, I think I can help. At least in finding duplicates.
[22:30] <jeromeg> you mean mr_pouit  mr_pouit  mr_pouit  gpocentek  gpocentek  and gpocentek  ?
[22:30] <daigorobr> Not a real programmer (actually a physician), but will do my best.
[22:30] <charlie-tca> I'm not a programmer or developer, but can I help?
[22:31] <jeromeg> daigorobr: you don't need to know anything about programming to triage bugs
[22:31] <jeromeg> charlie-tca: yes
[22:31] <sectech> No, no you don't... I am a good example of that :P
[22:31] <daigorobr> jeromeg: see, there are some things thtat you have to know the inner functioning to triage and forward properly.
[22:31] <charlie-tca> a couple of hours a day, 3 times a week?
[22:32] <jeromeg> charlie-tca: as you want
[22:32] <sectech> charlie-tca, as much or as little as you want
[22:32] <cody-somerville> jeromeg, I have to admit that I really don't find your negative attitude helpful. I think if we want positive results, we need to act positive as well.
[22:32] <daigorobr> ;me nods
[22:32] <daigorobr> Ops.
[22:32] <jeromeg> cody-somerville: I'm not negative, I'm realistic
[22:32] <mr_pouit> but thinking that people would come by magic isn't a good atitude either :]
[22:32] <cody-somerville> People won't come by magic.
[22:32] <daigorobr> jermoeg: you're on the half-empty side. But that's okay, I think.
[22:33] <cody-somerville> My strategy is generate buzz, energy, and excitement about getting involved with Xubuntu.
[22:33] <cody-somerville> Organizing bug days
[22:33] <jeromeg> daigorobr: the inner of bug triaging isn't really programming, it's more protocol
[22:33] <cody-somerville> Bug jams
[22:33] <cody-somerville> And other fun stuff
[22:33] <zoredache> so where is the 'protocol' documented?  Is that linked to from the xubuntu contributors page?
[22:33] <daigorobr> I agree with cody that you have to grow the user base to grow the contributors base. So the distro has to be fun and interesting (and up to date).
[22:34] <gpocentek> zoredache: look for 'bugsquad' in the wiki
[22:34] <jeromeg> zoredache: look for bug triaging on the ubuntu wiki
[22:34] <cody-somerville> https://wiki.ubuntu.com/Bugs/HowToTriage
[22:34] <jeromeg> cody-somerville: thanks
[22:34] <jeromeg> zoredache: the protocol is the same for all ubuntu packages
[22:35] <jeromeg> cody-somerville: the problem with buzz is that it's buzz
[22:35] <cody-somerville> jeromeg, it certainly won't sustain Xubuntu, correct :)
[22:35] <zoredache> ok, so back to my the second part of my question... should that be linked to from http://www.xubuntu.org/devel#qa?  Because I don't see it there
[22:35] <sectech> One question... If you guys want to triage, are you going to only be going for the xubuntu bugs? and if so, how will you know it's specific to xubuntu?
[22:36] <jeromeg> sectech: well, you can do what you want
[22:36] <jeromeg> sectech: to know if it's specific to xubuntu
[22:36] <gpocentek> sectech: you'll learn while triaging
[22:36] <jeromeg> or it's already known
[22:36] <jeromeg> or you can't reproduce it with sometihng else than xubuntu
[22:37] <jeromeg> anyway, if you forward upstream a bug that is xubuntu only
[22:37] <sectech> gpo, I am on bug-control...  they all are treated the same pretty much to me (I don't go for one type of type of distro)
[22:37] <jeromeg> the devs won't kill you
[22:37] <jeromeg> they'll tell you it's caused by one of our patches
[22:37] <cody-somerville> A helpful page: https://bugs.edge.launchpad.net/~xubuntu-team/+packagebugs
[22:37] <jeromeg> and close the bug
[22:37]  * cody-somerville tackles jeromeg :P
[22:37] <jeromeg> thanks cody-somerville
[22:38] <cody-somerville> jeromeg, no discouraging people :P
[22:38] <jeromeg> if one does not feel confident enough to triage bugs
[22:38] <jeromeg> only testing and reporting bugs is appreciated
[22:38]  * cody-somerville nods nods.
[22:39] <jeromeg> (if there is someone else to triage)
[22:39] <cody-somerville> Ok, zoredache, sectech, daigorobr: You all want to get involved? :)
[22:39] <jeromeg> the Hardy release was particularly painful because there were no bugs reported
[22:39] <jeromeg> the seeds were broken during a few weeks because no one reported it...
[22:40] <jeromeg> zoredache, sectech, daigorobr: I advise you to start little by little
[22:40] <sectech> brb a sec
[22:41] <jeromeg> and do not hesitate to ask questions
[22:41] <zoredache> I suspect I will try to help.  That bug triage page is useful.
[22:41] <jeromeg> zoredache: indeed, it links to a lot of useful stuff
[22:41] <charlie-tca> Ask questions where?
[22:42] <jeromeg> #ubuntu-bugs
[22:42] <jeromeg> #ubuntu-motu
[22:42] <jeromeg> #xubuntu-devel
[22:42] <jeromeg> #xfce to know if other people have the same bug with a different distro
[22:43] <cody-somerville> I strongly recommend hanging out in #xubuntu-devel
[22:43] <cody-somerville> And feel free to bug me with questions and what not
[22:43] <cody-somerville> I'm very eager to see more contributors join our ranks :)
[22:43] <jeromeg> mr_pouit and gpocentek are also very helpful
[22:43]  * cody-somerville nods.
[22:44] <jeromeg> don't hesitate to ask something to them ;)
[22:44] <cody-somerville> mr_pouit and gpocentek are both core-devs so they're very knowledgeable. jeromeg himself is a very talented bug triager and has developed an art to dealing with upstream so be sure to bug him too :)
[22:45] <jeromeg> cody-somerville: well, as I'm only on #xfce, and #xfce-dev I'm quite ahrd to reach for english speaking users
[22:45] <cody-somerville> If there is anything we can do that you feel would make it easier for future contributors to get involved, please take initiative to make it so or discuss it! :)
[22:45] <jeromeg> but feel free to mail me
[22:45] <cody-somerville> jeromeg, I can help you configure your client to auto-join #xubuntu-devel ;]
[22:46] <jeromeg> cody-somerville: it used to do so, but my hands removed this line ;)
[22:46] <cody-somerville> jeromeg, ;]
[22:46] <cody-somerville> Anyhow, what about marking bugs release critical?
[22:46] <daigorobr> #xubuntu devel it is, then
[22:46] <cody-somerville> Whats the best way to do this in everyone's opinion?
[22:47] <jeromeg> cody-somerville: use a launchpad tag ?
[22:47] <jeromeg> or simpler
[22:47] <jeromeg> put [Xubuntu] at the beginning of the bug title
[22:48] <jeromeg> and mark it as critical
[22:48] <sectech> About the bug triaging...  I really can't be specific (in all fairness) to give priority to xubuntu bugs, but I certainly will keep an eye out for them
[22:48] <sectech> jeromeg, ... please don't do that lol
[22:48] <daigorobr> are you people talking about tagging as release blocker?
[22:48] <jeromeg> sectech: why ?
[22:49] <jeromeg> daigorobr: indeed
[22:49] <cody-somerville> slangasek, Whats your opinion?
[22:49] <slangasek> cody-somerville: ... waving (?)
[22:49] <sectech> jeromeg,  If your going to triage, it might be best to follow the wiki on setting status/importance.
[22:49] <slangasek> what am I being asked to have an opinion on?
[22:49] <cody-somerville> slangasek, marking release critical or release important bugs
[22:50] <slangasek> uh... it's a good idea to mark bugs as release-critical when they're release-critical? :-)
[22:50] <jeromeg> sectech: well, nobody cares about xfce packages, so if a bug is critical for an xfce package, mark it as critical ;)
[22:50] <cody-somerville> slangasek, How is that currently denoted?
[22:50] <cody-somerville> slangasek, There is milestones and targets
[22:50] <slangasek> if you're talking about bug importances, the 'critical' importance is not the right way to set that...
[22:50] <sectech> slangasek,  when they are indeed critical then of course... but I believe jeromeg is talking about taking any bug that related to xubuntu and marking them critical
[22:51] <slangasek> cody-somerville: https://wiki.ubuntu.com/RCBugTargetting is the process I'm currently following, though it's not formally ratified
[22:51] <jeromeg> sectech: nope, only critical ones ;)
[22:51] <jeromeg> i'm not that stupid
[22:51] <jeromeg> ;)
[22:51] <slangasek> cody-somerville: I think that gives you lots of room to maneuver as far as tracking bugs that are critical to you as a team
[22:52] <daigorobr> I think we should tag it as Xubuntu and follow the default procedure
[22:53] <sectech> I am getting the impression that there is a difference here though when you say "critical"....  Critical to the use of the application as per https://wiki.ubuntu.com/Bugs/Importance or "critical to releasing xubuntu"?
[22:53] <slangasek> and there can certainly be cases where a bug should be nominated & milestoned (i.e., put on the RM's radar) if it's on a xubuntu-only package; as long as everyone understands that this mainly just makes me pester xubuntu people more about fixing it, it doesn't automatically inspire other people to work on the bug :-)
[22:54]  * cody-somerville nods.
[22:54] <cody-somerville> slangasek, How can we easily see a list of bugs that are RC?
[22:54] <jeromeg> sectech: for me critcal to release xubuntu = set it to a milestone and critical = set it as critical
[22:54] <cody-somerville> slangasek, (for Xubuntu only)
[22:55] <daigorobr> I have to disagree with the concept of "xubuntu-only packages"
[22:55] <jeromeg> daigorobr: what do you mean ?
[22:55] <slangasek> cody-somerville: um, I guess you would need to tag the bugs and filter on your tag
[22:55] <jeromeg> cody-somerville: I think the mozilla-tema odes something like that
[22:55] <daigorobr> They're xubuntu deafult installed packages, but for exemple, I used to use a gnome session with xfce4 panel and pcmanfm for desktop.
[22:56] <daigorobr> It's all Ubuntu packages, but critical for us.
[22:56] <daigorobr> But it is only a semantic rant.
[22:56] <jeromeg> daigorobr: well, bugs are reported against a package, whatever distro you used to get it
[22:56] <daigorobr> Exactly.
[22:56] <sectech> "Critical" as per the wiki is different then what you are suggesting jeromeg
[22:56] <daigorobr> So I think we could tag those that are important for us, but follow the procedures.
[22:57] <sectech> jeromeg,  which is where we start getting into workflow issues
[22:57] <cjwatson> it's three minutes until the scheduled platform team meeting; should we wait a few minutes until you're finished, or will we need to move elsewhere?
[22:57] <cjwatson> (happy to do either)
[22:57] <cody-somerville> cjwatson, we'll move.
[22:57] <daigorobr> xubuntu-dev?
[22:57] <cody-somerville> xubuntu-devel, aye
[22:57] <cjwatson> don't let me chase you out if you're making good progress here
[22:58] <cody-somerville> :)
[22:58] <jeromeg> sectech: critical for me = not working at all on most computers
[22:59] <slangasek> jeromeg: the "critical" bug importance has a defined meaning which is different from whether a bug is a blocker for a release ("release-critical")
[23:00] <calc> hi
[23:00] <jeromeg> slangasek: yep, that's why I suggested to affect release critical bugs to a milestone
[23:00]  * asac waves
[23:00] <evand> hi
[23:00] <cody-somerville> moo
[23:00] <TheMuso> Hey folks.
[23:00] <evand> heh
[23:00]  * slangasek waves
[23:00]  * ogra waves
[23:00]  * cjwatson idly prods the topic-bot
[23:01] <bryce> heya
[23:01] <james_w> hi all.
[23:02] <liw> greetingses
[23:02] <cjwatson> Arne is on holiday, doko is travelling, so I think that's everyone
[23:03] <doko> I'm still online
[23:03] <cjwatson> doko: oh good, hello
[23:03] <cjwatson> first off, I wanted to give a brief state-of-the-onion on alpha 1
[23:03] <cjwatson> there's still a large number of merges to do, and I think a lot of them have been delayed by people working on 8.04.1
[23:04] <cjwatson> however, we are at least far enough through that the desktop is installable and the installer is threatening to work
[23:04] <cjwatson> there are some initial CD images up at least for alternate which may stand a chance of sort of working
[23:04] <cjwatson> desktop CD is probably a ways off yet
[23:05] <cjwatson> but I think it will probably make sense to do an alpha in the next week or so, assuming that Steve and the QA folks have a bit of bandwidth to deal with testing
[23:05] <cjwatson> (it can be pretty minimal for a first alpha)
[23:06] <calc> i guess someone will be updating the release schedule once alpha 1 has been released?
[23:06] <cjwatson> mdz reminded me earlier today that alpha 2 is currently scheduled for the same day as 8.04.1, which is probably suboptimal. Anyone object to moving it one week later?
[23:06] <cjwatson> calc: yes
[23:06]  * calc will be watching it closely for timing information on OOo uploads
[23:06] <calc> ok
[23:06] <TheMuso> No objections here.
[23:06] <asac> makes sense
[23:06] <slangasek> cjwatson: I think moving alpha 2 a week later is the right thing here, yes
[23:07] <calc> makes sense to have some gap between a1 and a2 as well
[23:07] <cjwatson> done
[23:07] <calc> since it would be back to back weeks otherwise
[23:07] <cjwatson> ok then, outstanding actions from last week
[23:07] <cjwatson> lots of these, thanks to bryce's careful minuting :)
[23:07] <cjwatson> I'll just run down them quickly
[23:07] <cjwatson>  * ACTION: asac to make an informational spec out of intel connection
[23:07] <cjwatson>    manager session notes
[23:08] <asac> that one needs to be pushed back. still have it on my list, but considered it not high prio
[23:08] <cjwatson> ok, carried over
[23:08] <cjwatson>  * ACTION: asac + slangasek to discuss inclusion of ffox 3.0 final in
[23:08] <cjwatson>    the final 8.04.1 CD's
[23:08] <cjwatson> that's done, AFAICS?
[23:08] <slangasek> yes
[23:08] <asac> done. 3.0 is out. yes
[23:08] <cjwatson> well done for getting it into -updates on release day
[23:08] <asac> :)
[23:08] <cjwatson>  * ACTION: calc to make an informational spec for the ooo release
[23:08] <cjwatson>    schedule session notes
[23:09]  * ogra applauds
[23:09] <calc> done
[23:09] <cjwatson> calc: I see a spec now - perhaps also add something in the form of a calendar? I think that would be useful for comparison
[23:09] <calc> cjwatson: ok will do
[23:09] <cjwatson> thanks for the spec, though
[23:09] <cjwatson>  * ACTION: calc to provide updated OOo priority reports to Sun
[23:09] <bryce> asac, kudos :-)
[23:09] <calc> working on that still, its more or less on a per bug basis
[23:10] <calc> doesn't really need to be an action item anymore afaict though
[23:10] <doko> well, keep it one until an email is sent out to the OOoo people
[23:10] <cjwatson> but some updates have happened since last week, at least?
[23:11] <calc> some but still have lots to do on that front
[23:13] <cjwatson>  * ACTION: cjwatson to locate notes for ooo-langpack spec
[23:13] <cjwatson> I just spent a moment looking for these, and I'm afraid to say I don't seem to have any
[23:13] <cjwatson> calc: can you reconstruct from memory?
[23:14] <calc> i can try, its been about a month so i will see what i can remember
[23:14] <calc> i'll write it up and see what you and doko can add it to from memory of the three of us :)
[23:15] <cjwatson> ok
[23:15] <cjwatson>  * ACTION: cjwatson to review Ago's wubi spec and decide assignment
[23:16] <cjwatson> evand: while I'm still in the process of reviewing specs in general, I can't actually find this one
[23:16] <evand> hrm
[23:16]  * evand digs
[23:16] <cjwatson> it's not on blueprints.launchpad.net/~ago
[23:16] <ogra> probably assigned to a team ....
[23:16] <evand> https://wiki.ubuntu.com/WubiIntrepid
[23:17] <cjwatson> ah, not LP-linked
[23:17] <evand> I don't think he made a blueprint for it.  I mentioned it a while back to him.
[23:17] <evand> indeed
[23:17] <cjwatson> thanks, needs a good bit of work as a lot of that is still a pre-session dump
[23:18] <cjwatson> ok, carry that action over and I'll look at it
[23:18] <cjwatson>  * ACTION: evand to draft oem-system-recovery spec
[23:18] <evand> Still in the process of writing this one up.  It's taking me longer than I'd like as the only thing I have to go off of is a poor audio recording from the session, and I can't find a gobby session for it.
[23:19] <cjwatson> I think I was out for that session, so unfortunately I can't help
[23:20] <cjwatson> carried over
[23:20] <cjwatson>  * ACTION: doko to investigate if MoM's host machines has the disk space
[23:20] <cjwatson>    to do Testing and/or Experimental merges
[23:21] <doko> not yet done
[23:21] <cjwatson> ok, it's something you were interested in the answer to so it makes sense to stay on your plate I think
[23:21] <cjwatson>  * ACTION: [Volunteer Needed] to write the boot-performance spec
[23:22] <cjwatson> I don't think anyone stepped up for this
[23:22] <asac> who was in that session?
[23:22] <liw> I think I was
[23:22] <ogra> that somehow turned into fix mobile bootprobs
[23:22] <cjwatson> liw: you've had ~7 specs to write up already, though
[23:22] <liw> cjwatson, yeah
[23:23] <TheMuso> I was in that session.
[23:23] <TheMuso> Given good gobby notes, I could have a stab at it.
[23:23] <cjwatson> the notes are on https://wiki.ubuntu.com/UDS-Intrepid/Report/Platform
[23:23] <cjwatson> (as mentioned in the minutes last week)
[23:23] <TheMuso> Right.
[23:23]  * cody-somerville volunteers Keybuk.
[23:24] <cjwatson> it's a little vague, and might need a chat with Keybuk to flesh out
[23:24] <ogra> yeah
[23:24] <cjwatson> cody-somerville: he has a lot to do reviewing specs already, though :(
[23:24] <cjwatson> TheMuso: it's yours
[23:24] <cjwatson> thanks
[23:24] <ogra> he would be best for it though
[23:24] <TheMuso> Ok I'll have a look over the notes and take things from there.
[23:24] <cjwatson> he would, but it might be more practical to have somebody else suck his brains over IRC and write down the answers
[23:24] <cjwatson> for the moment
[23:24] <ogra> yeah
[23:25] <Keybuk> mmm, Brains
[23:25] <cjwatson> oh, hello Scott :-)
[23:25] <cjwatson>  * ACTION: Everyone not occupied with 8.04.1, spec writing, or urgent
[23:25] <cjwatson>    matters should focus on getting merge queue down
[23:25] <cjwatson> the merge queue is beginning to scare me a little bit, given the deadline for next week
[23:26] <cjwatson> 211 outstanding merges
[23:26] <Keybuk> it's not _that_ bad, at similar points in previous releases, we've only been slightly less behind
[23:27] <cody-somerville> I'll see what I can do this last half of the week.
[23:27] <Keybuk> but it's obviously non-zero ;)
[23:28] <cjwatson> on December 5 (a week and a day before hardy merges were due to be complete), needs-merge=174
[23:28] <cjwatson> so I suppose not too much worse, but still indicates we're behind
[23:28] <liw> cjwatson, what should we do about that? put more effort into processing merges?
[23:28] <cjwatson> anyone need help here?
[23:29] <cody-somerville> I do
[23:29] <cody-somerville> Bug #232364 is not being friendly to me :(
[23:29] <cjwatson> cody-somerville: is that a merge issue?
[23:29] <cjwatson> I have to admit I hadn't even looked at the universe merge queue yet
[23:29] <doko> well, I'm catching up, but maybe it's worth for the future not to list the uploader for mass/rebuild uploads (ok, that's selfish ;)
[23:30] <cjwatson> doko: I understand that it's possible for people with shell access to merges.u.c to override this ... ;-)
[23:30] <doko> gotcha
[23:30] <james_w> I have a question about one: https://bugs.edge.launchpad.net/ubuntu/+source/lvm2/+bug/239460
[23:31] <cody-somerville> cjwatson, Unfortunately no but I'd certainly be doing merges if I wasn't trying to fix that one ;]
[23:31] <james_w> I was touched-it-last as I cherry picked a small change just before release. I know very little about the package, but I did the merge. I submitted the merge request to get the bug number, and a red hat guy is obviously subscribed to the bug mail, and he suggested that we take a later version.
[23:33] <asac> james_w: he doesnt really provide much backup for his claim. but maybe worth to select the version with care
[23:33] <cjwatson> on the one hand, absolute stability is less important than it might be at this stage
[23:33] <cjwatson> on the other, no sense introducing wilful breakage
[23:33] <james_w> that's how I'm proceeding now, is that right? There's a small kink in that I don't feel comfortable in testing it, as I don't run any systems on lvm.
[23:34] <cjwatson> I think it's reasonable to work with the Debian maintainer on this
[23:34] <liw> james_w, can you run kvm? if so, setting up an lvm system should be fairly easy
[23:34] <james_w> yeah, I wasn't sure if he thought this was for release or something, but it's good to know, as Debian aren't guaranteed (or perhaps even likely) to update.
[23:34] <james_w> liw: not kvm, but yes, I can do that, but I'm not sure how much assurance that gives.
[23:35] <cjwatson> kvm should be OK for lvm
[23:35] <cjwatson> (it's only one character away!)
[23:35] <james_w> cjwatson: yep, I've filed an upgrade request, and I'm going to give it a bit longer to see if there is any response.
[23:35] <james_w> heh, is one test system enough with root-on-lvm?
[23:35] <cjwatson> I think it's OK for this to stretch a little longer past the merge deadline, anyway; lvm2 is something that tends to get a decent level of attention
[23:36] <liw> if lvm2 breaks, we'll hear it from slashdot, if not launchpad
[23:36] <bryce> will the merge deadline be affected by the alpha-1/alpha-2 rescheduling?
[23:36] <cjwatson> not significantly, I'd expect; alpha-1 doesn't require too much in the way of freezing
[23:37] <cjwatson> it's always been an "if it works, consider yourself lucky" kind of deal
[23:37]  * bryce nods
[23:38] <cody-somerville> ermm... what deadline next week btw?
[23:38] <bryce> cody-somerville: debian merges
[23:38] <cody-somerville> It is the Debian Import Freeze, not debian merge deadline :P
[23:39] <cjwatson> at DebianImportFreeze, each package ought to have been merged at least once
[23:39] <ogra> merges should be done by then by definition
[23:39] <cjwatson> see https://help.ubuntu.com/community/Debian/ImportFreeze
[23:39] <cjwatson> (CategoryDebian? huh?)
[23:39] <cody-somerville> So there is 211 packages that haven't been merged at all yet?
[23:39] <cody-somerville> *are
[23:39] <cjwatson> yes
[23:39] <cjwatson> in main
[23:40] <cody-somerville> Ah, I thought that was all pending merges.
[23:40] <cody-somerville> I understand your concern a little better now
[23:41] <cjwatson> that's what the "outstanding merges" bit means (well, actually, it roughly means hasn't been touched in Ubuntu since the new Debian version arrived, so a non-merge Ubuntu upload would also move it down to "updated merges")
[23:41] <cjwatson> anyway, I'll send a reminder to ubuntu-devel-announce
[23:41] <liw> DebianImportFreeze is on Thursday next week, if I read the calendar correctly
[23:41] <cjwatson> we can't magic up extra effort, but can try to chivvy people along
[23:41] <cjwatson> liw: correct
[23:42] <bryce> I've pretty much got all the xorg merges done for the time being so I can lend a hand with general merges over the next week
[23:42] <cjwatson> core developers could help by keeping an eye on the main sponsorship queues
[23:42] <cjwatson>  * ACTION: Everyone to make travel arrangements for Distro sprint
[23:42] <TheMuso> Done.
[23:43] <cjwatson> I'm poking you so that Claire won't have to. :)
[23:43] <liw> (coreutils should be ready for merging, unless I did something wrong)
[23:43] <asac> done
[23:43] <TheMuso> Just have to sort out getting from airport to hotel, but I'll probably email warthogs to ask if people are able to lend a hand...
[23:43] <liw> have flights, waiting for bag...
[23:43] <cjwatson> asac: please update wiki.c.c/DistroTeam/Sprints/Intrepid
[23:43] <TheMuso> ah yes of course
[23:44] <james_w> cjwatson: I assume those of us in the UK can delay a bit?
[23:44] <liw> TheMuso, do you know when you're arriving?
[23:44] <TheMuso> liw: Early the Sunday morning.
[23:45] <TheMuso> And I mean early. :)
[23:45] <cjwatson> james_w: if you're just getting the train over, not a problem
[23:45] <james_w> thansk
[23:45] <liw> TheMuso, then I am probably not of much help, I'm arriving in the afternoon
[23:45] <cjwatson> I assume you are, flying Bristol->London is a bit ridiculous unless you're a private pilot and want some flying time :)
[23:45] <slangasek> heh
[23:46] <cjwatson> TheMuso: Brian and Steve arrive at 0900, apparently
[23:46] <TheMuso> liw: Thanks anyway.
[23:46] <cjwatson> (Steve Beattie)
[23:46] <TheMuso> cjwatson: Unfortunately its somewhat earlier than that, I only had two choices for flights, and both got in about the same time./
[23:46] <evand> I arrive at 0840 :/
[23:47] <cjwatson>  * Location of minutes
[23:47] <TheMuso> Anyway, I'll send an email to warthogs about it.
[23:47] <cjwatson> a few people have said that meeting notes should go to ubuntu-devel, which I think is reasonable - this meeting is in a public channel anyway and I think at least some of it would be useful
[23:47] <cjwatson> any objections?
[23:47] <bryce> nope, I can ship them thataway
[23:47] <liw> cjwatson, I'm all for that
[23:48] <Keybuk> cjwatson: in which case, you'd know you can't land anywhere near London anyway ;-(
[23:48] <cjwatson> bryce: if you could also stick them on wiki.u.c somewhere for archival, that'd be good
[23:48] <TheMuso> Sounds fine to me re on -devel.
[23:48] <bryce> cjwatson: ok, I've been sticking them on wiki.canonical.com so far
[23:49] <cjwatson> those that were in public channels to start with can be moved, if you give the minutes a quick sanity-check for obvious partner discussions or whatever first
[23:49] <cjwatson> so agreed, then
[23:50] <cjwatson> any other business?
[23:50] <liw> good Midsummer!
[23:50] <TheMuso> If you use alsa apps on hardy regularly, please test with the alsa-lib in proposed.
[23:50] <TheMuso> We're pondering using alsa-lib 1.0.16 for 8.04.1, but it needs lots of testing...
[23:53] <cjwatson> yes, AIUI this is the biggest undecided thing for .1
[23:53] <asac> TheMuso: just general testing or is there anything we should focus on?
[23:53] <TheMuso> cjwatson: Indeed.
[23:53] <slangasek> asac: we're in need of rather broad regression testing
[23:53] <slangasek> i.e., "try it and tell us if it's broke"
[23:55] <liw> we could announce an attempt to break firefox's download record...
[23:55] <slangasek> heh
[23:56]  * calc thinks we don't have enough bandwidth for that
[23:56] <cjwatson> everyone here should be using hardy-proposed on hardy systems anyway :-)
[23:56] <cjwatson> but please do check out sound in general and report back
[23:56] <cjwatson> (FWIW I have seen - heard! - no regressions as yet)
[23:57] <liw> none of my ubuntu machines have sound :(
[23:57] <calc> 543 gigabit connection to break that for an iso ;-)
[23:57] <asac> i am quite a lame sound user and i have no sophisicated sound setup
[23:57] <cjwatson> three minutes before time and it sounds like we're pretty much done, so adjourned
[23:57] <cjwatson> thanks all
[23:57] <asac> thanks all
[23:57] <TheMuso> thanks folks./
[23:57] <slangasek> thanks
[23:57]  * TheMuso gets breakfast
[23:57] <james_w> thanks
[23:57] <liw> danke schön
[23:57] <bryce> thanks
[23:58] <evand> thanks
[23:58] <calc> thanks
[23:59] <cody-somerville> thanks