[12:59] <zul> @schedule
[12:59] <Ubugtu> Schedule for Etc/UTC: 09 Oct 14:00: MOTU | 10 Oct 20:00: Technical Board | 11 Oct 20:00: Edubuntu | 12 Oct 15:00: Ubuntu Development Team | 17 Oct 12:00: Community Council | 18 Oct 12:00: Edubuntu
[12:59] <zul> @schedule montreal
[12:59] <Ubugtu> Schedule for America/Montreal: 09 Oct 10:00: MOTU | 10 Oct 16:00: Technical Board | 11 Oct 16:00: Edubuntu | 12 Oct 11:00: Ubuntu Development Team | 17 Oct 08:00: Community Council | 18 Oct 08:00: Edubuntu
[01:00] <Hawkwind> @schedule chicago
[01:00] <Ubugtu> Schedule for America/Chicago: 09 Oct 09:00: MOTU | 10 Oct 15:00: Technical Board | 11 Oct 15:00: Edubuntu | 12 Oct 10:00: Ubuntu Development Team | 17 Oct 07:00: Community Council | 18 Oct 07:00: Edubuntu
[04:56] <freeflying|away> @schedule Shanghai
[04:56] <Ubugtu> Schedule for Asia/Shanghai: 09 Oct 22:00: MOTU | 11 Oct 04:00: Technical Board | 12 Oct 04:00: Edubuntu | 12 Oct 23:00: Ubuntu Development Team | 17 Oct 20:00: Community Council | 18 Oct 20:00: Edubuntu
[08:58] <siretart> @time europe
[08:59] <siretart> @time berlin
[08:59] <Ubugtu> Current time in Europe/Berlin: October 09 2006, 08:59:12 - Next meeting: MOTU in 7 hours 0 minutes
[08:59] <ajmitch> hi siretart  :)
[08:59] <siretart> heyho ajmitch!
[08:59] <GNAM> @schedule rome
[08:59] <Ubugtu> Schedule for Europe/Rome: 09 Oct 16:00: MOTU | 10 Oct 22:00: Technical Board | 11 Oct 22:00: Edubuntu | 12 Oct 17:00: Ubuntu Development Team | 17 Oct 14:00: Community Council | 18 Oct 14:00: Edubuntu
[09:07] <siretart> :)
[10:47] <sivang> @schdule Israel
[10:47] <sivang> @schedule Israel
[10:47] <Ubugtu> Schedule for Israel: 09 Oct 16:00: MOTU | 10 Oct 22:00: Technical Board | 11 Oct 22:00: Edubuntu | 12 Oct 17:00: Ubuntu Development Team | 17 Oct 14:00: Community Council | 18 Oct 14:00: Edubuntu
[11:20] <lucas> @schedule paris
[11:20] <Ubugtu> Schedule for Europe/Paris: 09 Oct 16:00: MOTU | 10 Oct 22:00: Technical Board | 11 Oct 22:00: Edubuntu | 12 Oct 17:00: Ubuntu Development Team | 17 Oct 14:00: Community Council | 18 Oct 14:00: Edubuntu
[11:20] <lucas> ok, won't make it.
[11:38] <Fujitsu> @now
[11:38] <Ubugtu> Current time in Etc/UTC: October 09 2006, 09:38:35 - Next meeting: MOTU in 4 hours 21 minutes
[02:46] <freeflying> @schedule Shanghai
[02:46] <Ubugtu> Schedule for Asia/Shanghai: 09 Oct 22:00: MOTU | 11 Oct 04:00: Technical Board | 12 Oct 04:00: Edubuntu | 12 Oct 23:00: Ubuntu Development Team | 17 Oct 20:00: Community Council | 18 Oct 20:00: Edubuntu
[03:55] <freeflying> @schedule Shanghai
[03:55] <Ubugtu> Schedule for Asia/Shanghai: Current meeting: MOTU | 11 Oct 04:00: Technical Board | 12 Oct 04:00: Edubuntu | 12 Oct 23:00: Ubuntu Development Team | 17 Oct 20:00: Community Council | 18 Oct 20:00: Edubuntu
[03:56] <sivang> so, MOTU meeting is now?
[03:56] <dholbach> anytime soon, yes
[03:57] <Toadstool> hey here
[03:58] <freeflying> hi all
[04:00] <Gloubiboulga> hello
[04:00] <zul> hi
[04:01] <dholbach> OK everybody - welcome to the MOTU meeting
[04:01] <Gloubiboulga> I can only stay ten minutes :/
[04:01] <dholbach> We try to keep this meeting short, as we all want to get back to fixing the last bugs in Edgy. :-)
[04:01] <dholbach> Our agenda is quite short, it's over here: https://wiki.ubuntu.com/MOTU/Meetings
[04:01] <dholbach> First point on the agenda is: "Prepare check lists for Universe/Multiverse for release."
[04:02] <dholbach> In the previous release cycles we always had lists of things we wanted to get done
[04:02] <dholbach> like the python transition, the unmet dependency lists, ftbfs lists and other transitions
[04:02] <dholbach> not to forget: Bug lists!
[04:02] <dholbach> What do we have on the plate for Edgy release?
[04:03] <Fujitsu> We ideally need to get a FTBFS list, 'cause an unmet deps. list is trivial...
[04:03] <dholbach> Ok
[04:03] <dholbach> 1) UnmetDeps list - easy to do, we can massfile bugs on that one
[04:03] <Fujitsu> Yup.
[04:04] <dholbach> 2) for the FTBFS list we can take the list of failed builds on launchpad
[04:04] <dholbach> because I think that Adam (infinity) is too busy to do an archive rebuild at this stage.
[04:04] <Fujitsu> dholbach, not really. A lot of things haven't been built in ages.
[04:04] <Fujitsu> Yeah, true.
[04:04] <dholbach> if anybody else has a feasible idea on that one, I'm all ears. :-)
[04:05] <dholbach> Do we have any open transitions we don't get by looking at the unmet deps list?
[04:05] <sivang> dholbach: what about the python transition, is it all done ?
[04:06] <dholbach> sivang: for Universe: I doubt it
[04:06] <sivang> I see :-/
[04:06] <dholbach> sivang: doko_ fixed a lot and synced a lot from Debian, but I guess it's not complete (for Universe)
[04:06] <sivang> yes, I see
[04:06] <dholbach> Ok - anything else specific for the last days before release?
[04:07] <dholbach> (If you can think of anything later on, just mail ubuntu-motu@)
[04:08] <siretart> dholbach: we have that gnustep transition open
[04:08] <dholbach> siretart: ah! how many packages does that involve?
[04:08] <siretart> dholbach: you surely remember a series of UVF exceptions the last dats
[04:08] <dholbach> siretart: yeah I do - are there other packages involved?
[04:08] <siretart> dholbach: I'm not sure as I'm not familiar with gnustep at all
[04:08] <dholbach> I see
[04:09] <dholbach> I'll follow up with him.
[04:09] <siretart> I remember a message from debian-release@lists.debian.org, that this transition isn't complete even in debian/etch
[04:09] <dholbach> I'll write him after the meeting - let's hope we get that done for release
[04:09] <siretart> ok
[04:10] <sistpoty> what's that transition about... I remember quite a bunch of gnustep uploads at the beginning of edgy...
[04:10] <geser> the gnustep transition will need several packages to be rebuilt or synced but I haven't checked in detail yet
[04:10] <geser> I'm still trying to get all pieces built
[04:10] <minghua> gnustep transition is almost finished in Debian from what I read from debian-release list
[04:11] <minghua> some packages are still in NEW
[04:11] <geser> gnustep-back needs to be built
[04:11] <sivang> yes, also curious to know what the gnustep transition is about
[04:11] <sistpoty> maybe s.o. could investigate and post to ubuntu-motu@l.u.c?
[04:11] <dholbach> Ok, that sounds as if we're on a good way to get it fixed.
[04:12] <siretart> yes, lets not block the meeting with that transitions. let's move on
[04:12] <dholbach> For Universe/Multiverse Bugs:         1   75  of 2778 results            is, what I currently see.
[04:12] <dholbach> What is a good way to address those bugs?
[04:12] <dholbach> ( http://tinyurl.com/p7moy )
[04:12] <StevenK> dholbach: Close the lot of them, of course.
[04:12] <dholbach> ;-)
[04:12] <dholbach> Right.
[04:13] <Fujitsu> Write a script that iterates through and rejects them. Problem solved.
[04:13] <StevenK> dholbach: Some of those 2778 probably apply to Hoary which can be found and slaughtered.
[04:13] <Fujitsu> We have a bug-free universe.
[04:13] <dholbach> I'm sure that a lot of old ones can indeed be rejected.
[04:13] <Fujitsu> StevenK, probably.
[04:13] <dholbach> that's rather a task for the opening of edgy+1
[04:14] <Fujitsu> True...
[04:14] <dholbach> in the process of uploading a fix for universe and multiverse in the last days we should always make sure to check the bugs in launchpad for that package
[04:14] <dholbach> that way we can easily find bugs that can be closed with the upload and some even point to the debian bug with a patch
[04:14] <Fujitsu> I've generally tried to do that for all of my uploads.
[04:14] <dholbach> Fujitsu: Good work!
[04:15] <dholbach> 1   75  of 157 results     Uni/Multiverse bugs with patches
[04:15] <dholbach> those are lowhanging fruit, I guess
[04:15] <siretart> dholbach: I don't really see what we as motu team can decide or discuss about high bugnumbers, besides encouraging to participate in bug squashing sessions
[04:15] <dholbach> I'll write a mail to ubuntu-motu@ about that later on
[04:15] <dholbach> siretart: I only try to identify low-hanging fruit
[04:16] <dholbach> things we can get fixed easily.
[04:16] <siretart> dholbach: what we can do is to try to create reports about how many bugs we have open, how many are confirmed, important and have a patch, and list them in a report
[04:16] <dholbach> siretart: nice idea - that would go well into a MOTU section on UWN
[04:16] <sistpoty> from taking a glimpse on some bugs, some basic triaging (getting info etc.) might help... maybe we could do a hug day?
[04:16] <siretart> in the hope that this encourages uploaders actually looking at bugs. debian has a weekly report about RC bugs
[04:16] <dholbach> sistpoty: sure - sfllaw will be happy to see some people working on universe packages
[04:17] <dholbach> Ok, I'll write a mail about Universe bugs.
[04:17] <sistpoty> dholbach: great!
[04:17] <dholbach> Who wants to massfile bugs on unmet deps?
[04:18] <dholbach> I have a script for that - but if somebody else wants to do that, that's cool
[04:18] <Fujitsu> I can do it, if others won't :)
[04:18] <dholbach> Fujitsu: I think I'll also point to the failed builds on launchpad
[04:18] <dholbach> Fujitsu: http://daniel.holba.ch/bzr/massfile
[04:18] <Fujitsu> Thanks.
[04:18] <sistpoty> would be good to have the packagename in the bug title (i guess that was a script bug last time *g*) ;)
[04:18] <dholbach> hehe :-)
[04:18] <dholbach> ok, let's move on - if some of you have clever ideas which bugs/fixes to address - follow up on the mailing list
[04:19] <siretart> and tag them! :)
[04:19] <dholbach> 2) Find agreement on StableReleaseUpdates for Universe/Multiverse
[04:19] <dholbach> https://wiki.ubuntu.com/StableReleaseUpdates
[04:19] <Fujitsu> Yes, that's particularly important to me, as I've got an update or two that need doing ;)
[04:19] <siretart> dholbach: 1st question: do we have a -proposed upload target for universe?
[04:19] <dholbach> Usually shortly after releases we get lots of requests for updates to <stable>-updated
[04:19] <dholbach> -updates
[04:20] <dholbach> siretart: I'm not quite sure, I'll investigate and let you all know.
[04:20] <sistpoty> just curious: did anyone do a SRU for uni/multiverse recently?
[04:20] <dholbach> not recently
[04:20] <siretart> dholbach: is someone only who we can ask? because I think this could be important for our further discussion of this point
[04:21] <siretart> s/only/online/. gnarf
[04:21] <siretart> sistpoty: I think LaserJock tried to do one, but mdz told him that we need a process for that first
[04:21] <siretart> sistpoty: thats why we are discussion that here
[04:21] <dholbach> I asked in #ubuntu-devel
[04:22] <siretart> thanks
[04:22] <sistpoty> imo the entry barrier as proposed in SRU-updates is too high for universe... 
[04:22] <dholbach> that's my feeling too, sistpoty
[04:22] <Fujitsu> siretart, I see an SRU for matplotlib by LaserJock.
[04:22] <sistpoty> maybe we could get s.th. like motu-uvf in place for SRU policies and just get a final ack after the -proposed upload from ubuntu-archive?
[04:22] <siretart> Fujitsu: oh. i see
 What is the current state of -proposed? Does it work? Does it work for universe and multiverse as well?
[04:22] <sivang> what's the SRU?
 dholbach: working but restricted by policy (StableReleaseUpdates); yes; yes
[04:22] <dholbach> sivang: STABLE RELEASE UPDATES
[04:22] <sivang> dholbach: ah, right, sorry ! :-)
[04:22] <dholbach> *cough* :)
[04:23] <sivang> hehe
[04:23] <siretart> I like sistpoty's idea (in fact, I wanted to propose something similar)
[04:23] <dholbach> sistpoty: how do you think the testing process should work?
[04:23] <dholbach> ... testing part of the process ...
[04:24] <sistpoty> dholbach: just some ideas so far...:
[04:24] <sistpoty> only updates allowed with bug numbers
[04:24] <sistpoty> then we could "abuse" the ppl. filing the bugs to participate in testing
[04:25] <siretart> (they are likely interested in actually testing fixed packages)
[04:25] <sistpoty> the motu-uvf-alike team would also need to do some basic tests I guess
[04:25] <dholbach> yeah that's the interesting part of the question: who do we ask to test?
[04:25] <dholbach> bug reporters: good idea
[04:26] <siretart> dholbach: the bug submitters and subscribed ppl to that lp bug
[04:26] <dholbach> motu-uvf: bad idea - too much mails already ;-)
[04:26] <dholbach> siretart: do you think that's enough?
[04:26] <siretart> dholbach: let's call that group 'motu-sru'
[04:26] <sistpoty> yay
[04:26] <sistpoty> of course the uploader needs to test thoroughly *g*
[04:27] <siretart> dholbach: I think yes. we cannot afford the same level of testing as in main
[04:27] <dholbach> and that would be people who agree to do tests in the stable release now and then?
[04:27] <rmjb> uvf?
[04:27] <dholbach> rmjb: upstream version freeze
[04:27] <dholbach> What about mailing them to UWN and announcing them - for people to test and have a look?
[04:27] <siretart> dholbach: I don't understand, announce what exactly?
[04:27] <dholbach> that would make sure we have a reasonably big tester community
[04:28] <dholbach> "fixed packages of <...> available for testing."
[04:28] <siretart> in form of a report section of UWN? sounds great!
[04:28] <dholbach> yeah
[04:28] <minghua> sounds a good idea, but I'm not sure how well that will work
[04:28] <Fujitsu> Although some bugs already have large communities built up around them, so have a large testing ground already :P
[04:28] <sistpoty> dholbach: sounds great... maybe we could increase the testing time a little bit (2-4 weaks?)?
[04:28] <Toadstool> dholbach: and point the testers to the sru bug report, otherwise we'll get a whole load of dupes :)
[04:29] <sivang> Yes, sounds like UWN would encourage people to do testing.
[04:29] <siretart> minghua: we have to test. do you have another proposal?
[04:29] <dholbach> because we need to get thorough testing done: be honest: all of us run the development release and seldomly test stuff in the last stable
[04:29] <minghua> I have some input method related package I want to propose for SRU, but I doubt many testers are interested in testing them
[04:29] <sistpoty> dholbach: so that proposed will become a kind of testing *g*
[04:29] <dholbach> sistpoty: >= 2 weeks - yes, what I thought
[04:29] <sivang> dholbach: well, setting up a dapper chroot is not hard :)
[04:29] <siretart> dholbach: how does the -propsed queue work? do uploads get automatically built and published?
[04:29] <minghua> siretart: not really, but I think the uploader/proposer should be more responsible
[04:30] <dholbach> sivang: thoroughly using it, is
[04:30] <dholbach> minghua: we have a cjk-testers team in launchpad - maybe you could subscribe them to that bug?
[04:30] <dholbach> siretart: yes, in the <stable>-proposed section
[04:30] <sistpoty> just a side though: we should try to limit new upstream versions though, maybe only for utterly broken packages or small diffs, since these would be a target for -backports imo
[04:30] <sivang> so, that measn testers will have to have another box runnign dapper..
[04:31] <minghua> dholbach: a lot of bugs I want to fix have cjk-testers subscribed, not much activity from what I see
[04:31] <dholbach> sistpoty: agreed
[04:31] <siretart> dholbach: cool. I imagined that would be a moderated queue, similar to NEW or something
[04:31] <sivang> sistpoty: indeed, make a lot of sense.
[04:31] <dholbach> minghua: you could try to prod jono about making the team more active - maybe ask in the loco teams to get people involved there
[04:31] <Fujitsu> sistpoty, of course.
[04:31] <minghua> dholbach: sure, I'll think more about this
[04:31] <dholbach> Wow, looks like we got some good ideas on that one.
[04:32] <siretart> :)
[04:32] <minghua> I'm just expressing my interest on SRU for universe here :-)
[04:32] <sistpoty> for testing, maybe we could make some silly "acks >= n" guidelines for packages, to see if updating in fact makes sense
[04:32] <dholbach> Anyone wants to add something to it?
[04:32] <dholbach> minghua: :-)
[04:32] <freeflying> minghua: anything relate to zh_CN, ubuntu-cn would like test 
[04:32] <minghua> I think strict ack >= n is a good idea
[04:33] <dholbach> might be a bit tough for obscure packages
[04:33] <sivang> sistpoty: I'd say not >= , but they will have to provide X benefits on ground which we will update them.
[04:33] <dholbach> but this is something we'll figure out along the way
[04:33] <minghua> freeflying: not really, the things I have in my head is scim-chewing and scim-m17n
[04:33] <minghua> freeflying: but thanks for the information
[04:33] <sivang> so having something like "Does it fulfill A,B,C and E? okay let's update"
[04:33] <dholbach> We need to flesh out this process perfectly, so it'll be easy for people to get involved in approving, forwarding, testing, etc
[04:33] <minghua> freeflying: on the other hand, most zh_CN related scim stuff are in main anyway
[04:33] <sistpoty> I wouldn't make it a strict policy (as dholbach just mentioned)... but rather a guideline which the sru-team could still override
[04:33] <freeflying> minghua: but we wtill can test
[04:33] <dholbach> yeah
[04:34] <rmjb> testing on stable can be done in a virtual appliance? if users are running development?
[04:34] <dholbach> Ok - let's put all of this into a wiki page later on and work on it together
[04:34] <sivang> rmjb: for sure
[04:34] <minghua> back to the ack >= n thing - if we can't get enough acks, it should mean not many users are interested in this package, shouldn't it?
[04:34] <siretart> did we agree on a 'motu-sru' team? how many members and what quorum do we want to have?
[04:35] <sivang> and when Xen is ready in edgy, it will even come out of the box IIRC.
[04:35] <dholbach> I have the feeling that we won't solve the process entirely today.
[04:35] <sivang> we need to start with somethign modest,
[04:35] <sivang> and refine the process as we go
[04:35] <sistpoty> minghua: it would... but some obscure packages that are utterly broken anyway would get of starved from this... so I'd make it just a guideline which can be overridden...
[04:35] <sivang> *something
[04:36] <Fujitsu> dholbach, of course, there is a lot to be decided.
[04:36] <dholbach> Yes
[04:36] <sivang> We can start with a very basic set of guidlines, and see what more we require by experience
[04:36] <rmjb> the sru will also apply to dapper since that's LTS or does that already have something in place?
[04:36] <sistpoty> minghua: also, testing by s.o. who's really knowing what he's doing is worth more then 5 tests of ppl. who don't have much clue ;)
[04:36] <minghua> freeflying: you mean ubuntu-cn can still test packages in main, or test packages not about zh_CN?
[04:36] <dholbach> I'll start on https://wiki.ubuntu.com/MOTU/Processes/SRU later on and will try to make the wiki page so everybody can add their proposal in easily
[04:36] <dholbach> we should discuss the strict guidelines in another meeting
[04:36] <siretart> or perhaps on the mailing list
[04:37] <dholbach> good idea too
[04:37] <sistpoty> +1
[04:37] <sivang> +1
[04:37] <Fujitsu> +1
[04:37] <dholbach> so it gets some eyeballing before we finally agree in a meeting
[04:37] <freeflying> minghua: we'd like test anything we can do :)
[04:37] <siretart> next item?
[04:37] <minghua> sistpoty: very true.  if some one is willing to be responsible for the upload, then things can be overridden. :-)
[04:38] <dholbach> MOTU Build Farm and Donation (HW, CPU time, and $) process (JordanMantha)
[04:38] <dholbach> laserjock is not here
[04:38] <dholbach> I think we probably should leave this one out for the next meeting - what do you guys think?
[04:38] <sistpoty> yep
[04:38] <minghua> is TheMuso here?
[04:38] <TheMuso> TO be honest, I think its something that should be discussed on the ml.
[04:38] <siretart> dholbach: perhaps you can give some details about this proposal?
[04:38] <minghua> the proposal mail to -motu is his
[04:38] <TheMuso> Its not something thats easily talked about on IRC>
[04:38] <bddebian> I think some should just send me a PPC, Sparc, and amd64 and be done with it.. ;-P
[04:39] <siretart> bddebian: I have a spare ultra1 ;)
[04:39] <dholbach> siretart: I have no idea
[04:39] <dholbach> siretart: it's his item :)
[04:39] <siretart> ic
[04:40] <siretart> hm. the original proposal was from Luke Yelavich 
[04:40] <siretart> dholbach: can we abuse edgy-proposed for that?
[04:40] <TheMuso> A few of us were talking about it in -motu earlier today, and were throwing ideas around, but due ot the complexity of what might have to be done, I feel it it would be easier on the mailing list.
[04:40] <dholbach> siretart: for what?
[04:40] <TheMuso> IMO
[04:40] <Fujitsu> I think this is fairly important, because I've run into a couple of bugs/FTBFSes in various things that only appear in PPC or [insert other obscure architecture here] . It's pretty much impossible to debug this sort of stuff without access to machines of the target architecture.
[04:40] <siretart> dholbach: testuploading packages to see if they build on all architectures or for testing of patches?
[04:40] <Fujitsu> And not all of us have non-x86 machines.
[04:40] <dholbach> hmrmhrmhmrmhrmhrmhrmhrmhr
[04:41] <dholbach> I don't like the idea much - the buildds are usually somewhat blocked already
[04:41] <TheMuso> I wasn't thinking of using the build servers.
[04:41] <siretart> dholbach: buildds can be prioritized. I imagine that very low priority
[04:41] <Fujitsu> *cough* openoffice *cough* kde *cough*
[04:41] <dholbach> not blocked, but you know that other stuff will be delayed
[04:41] <dholbach> I don't like the idea much
[04:42] <TheMuso> I am very well aware of their busy schedule.
[04:42] <dholbach> you can ask on #ubuntu-devel - as it's not my decision
[04:42] <sistpoty> imo it's not so much the problem to test if a package builds on all arches before a package is uploaded, but rather to get access to arch-xy if there is a build-failer on that arch
[04:42] <TheMuso> Has everybody here read the original email I sent?
[04:42] <sistpoty> failure even
[04:43] <minghua> TheMuso: I read :-)
[04:43] <minghua> I think TheMuso's idea is not really a build farm, but something like Debian's developer's machine for all archs
[04:44] <minghua> which MOTUs can log in and do test builds or debugging
[04:44] <minghua> TheMuso: is that correct?
[04:44] <minghua> and in that case we don't need the official buildds
[04:44] <minghua> some machines in a MOTU's house works just fine
[04:45] <TheMuso> minghua: SOmewhat. I was thinking of something where anybody who has hardware can donate its use for building/testing, but on a purely volintary basis.
[04:45] <Fujitsu> Like what a couple of people do now.
[04:45] <TheMuso> And have such systems in place so that if a user donates hardware, but has low bandwidth, their systems only build small packages. Same with CPU speed, and times of day.
[04:45] <TheMuso> Fujitsu: Exactly.
[04:46] <TheMuso> ajmitch raised some interesting points about security. I'd have to dig back through my -motu logs to find them however.
[04:46] <_MMA_> Hello all. LaserJock and I talked at some length about this. I have a AMD AM2 4600+ machine that I would like to compile packages on. Currently I cant package. I wanna learn but my current situations gives me limited time to learn new things. So we discussed I could process files without configuring everything.
[04:47] <_MMA_> I also wanted to donate some $ for hardware.
[04:48] <dholbach> Can we start getting ideas together on a wiki page for that?
[04:48] <dholbach> It looks like it's not something we can decide easily
[04:48] <TheMuso> Thats a good idea.
[04:48] <sistpoty> hm... just as a side idea: maybe we could also form amd64/sparc/ppc/whatever teams, that have access to that hw and to whom we could assign arch-specific bugs to. usually it's easy for s.o. who has that arch to fix the bug because he will know what's the problem
[04:49] <StevenK> That's a big assumption.
[04:49] <sistpoty> well.. usually as in for the easy fixes... of course there are tough tasks, which the team could reject then
[04:49] <StevenK> I own an sparc64 and a parisc, doesn't mean I know anything about how the software functions in comparsion to an i386
[04:49] <TheMuso> StevenK: Same with myself and my ppc.
[04:50] <rmjb> sistpoty: with this proposal the person with the knowledge of the package can fix the bug since they'll have access to the different arches
[04:50] <dholbach> we could add a subpage to the wiki about people and their hardware
[04:50] <sistpoty> rmjb: sure... it was just an extra idea on top of that
[04:50] <dholbach> and decide on a process to form those teams, etc
[04:50] <tomveens> wiki idea: need a spokesperson for the page a one point to communicatie with about HW donation
[04:51] <dholbach> http://wiki.ubuntu.com/MOTU/Machines ;-)
[04:51] <sistpoty> the motu-machines :)
[04:51] <TheMuso> heh
[04:51] <dholbach> we can add all the security worries, process ideas, lists, mail addresses, everything to it
[04:51] <tomveens> who's first?
[04:52] <dholbach> I suggest we do that before we start to decide on something :)
[04:52] <dholbach> but it was great to see some ideas thrown into the mix ;-)
[04:52] <TheMuso> dholbach: Agreed. I just wanted to get it out in the open.
[04:52] <dholbach> TheMuso: thanks a lot for that.
[04:52] <TheMuso> np
[04:52] <dholbach> next time and date?
[04:52] <dholbach> I'd like to have it after the release
[04:53] <Fujitsu> A couple of days after?
[04:53] <TheMuso> Does anybody mind if I create the wiki page dholbach suggested above
[04:53] <dholbach> Fujitsu: sounds good
[04:53] <Fujitsu> Go ahead, dholbach.
[04:53] <tomveens> okay
[04:53] <TheMuso> SO I can flesh out my original proposal a little more?
[04:53] <dholbach> between release and UDS, after?
[04:53] <Fujitsu> Oops, *TheMuso, not dholbach.
[04:54] <TheMuso> :)
[04:54] <dholbach> Ok, we can handle that on the mailing list as well.
[04:54] <dholbach> Thanks a lot everybody for coming to the meeting!
[04:55] <TheMuso> np
[04:55] <sistpoty> thanks for the meeting ;)
[04:55] <dholbach> Have a good time until the release - I know you're all going to ROCK!
[04:55] <Fujitsu> THanks for running it :)
[04:55] <dholbach> de rien :)
[04:55] <Fujitsu> No, no rocking. Sleeping now :P
[04:55] <dholbach> Fujitsu: sleep tight.
[04:55] <TheMuso> Fujitsu: SOunds like a plan.
[04:55] <TheMuso> That page is going up tomorrow.
[04:55] <Fujitsu> Thanks dholbach :)
[04:55] <Fujitsu> Good idea, TheMuso.
[04:55] <Fujitsu> 'tis late.
[04:55] <Fujitsu> Or early.
[04:56] <TheMuso> Yeah. And I don't feel very awake. :p
[04:56] <Fujitsu> Neither.
[04:56] <Fujitsu> See you all on the morrow.
[05:06] <bddebian> Hey, what'd I miss.  Can you all start over? ;-P
[05:11] <Hobbsee> bddebian: heh