[12:08] <dholbach> that's why i'd like to introduce another idea for solving this: in my opinion what makes a transition a good one, is a good plan
[12:09] <dholbach> so having somebody responsible for a task who keeps an eye on it, is more important
[12:09] <\sh> when there are more work then in normal times (breezy is not really normal)
[12:09] <dholbach> a aalib transition manager or something
[12:09] <dholbach> for example
[12:09] <\sh> s/are/is/
[12:09] <siretart> dholbach: this would my my suggestion/expectations from the teams
[12:09] <dholbach> the c++ transition was a good example for this - our beloved doko did an awesome job in planning this
[12:09] <bddebian> dholbach: That's mor along the lines of what I was thinking
[12:09] <\sh> then we should split up our strength, and say ok, 5 members here, 5 members there and 5 members are doing something else also important
[12:09] <siretart> dholbach: having a lead and interested people for a specific topic which need to get done
[12:10] <siretart> the lead should have an overview and be able to explain what is going on
[12:10] <dholbach> absolutely
[12:11] <dholbach> write a nice wiki page, with notes about the transition and a list to tick things off - and pushes people into it, creates some party atmosphere behind it all :)
[12:11] <Seveas> this sounds just like the way tasks are planned already in ubuntu: One lead, perhaps a second and a bunch of worker drones
[12:11] <ajmitch> dholbach: sounds good, just like what you did for hoary ;)
[12:11] <bddebian> Seveas: Where is this happening?
[12:11] <dholbach> ajmitch: thanks for the flowers :-p
[12:12] <Seveas> bddebian, http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
[12:12] <ajmitch> bddebian: breezy goals, lead & seconds were assigned at the kickoff meeting
[12:12] <\sh> actually, I don't like the lead stuff for those works
[12:12] <bddebian> Seveas: Ah, nice
[12:12] <dholbach> \sh: they're not supposed to do the work all themselves
[12:13] <\sh> dholbach: right..but this I don't mean...
[12:13] <dholbach> ah ok... maybe i got you wrong
[12:13] <ogra> \sh, you need a point of contact... someone who is responsible and trys to coordinate a bit
[12:13] <ajmitch> you want more of a coordinator
[12:13] <\sh> ok, we have some good members working on sources..the others are working as good reviewers..so everybody has their own field, right?
[12:14] <dholbach> i'm not quite sure, if all the stuff doesnt really go hand in hand
[12:14] <dholbach> i mean reviewing and fixing is all about fixing source packages :)
[12:14] <\sh> so if there is a lot of "source" work to do, those members will help in the transitions, while the others are doing review or new motu trainings etc.
[12:15] <ogra> yes, both teaches you a lot... you shouldnt do one without the other
[12:15] <\sh> the rest of the time, it will stay like normal work...merges, new uploads, sourcework, review, training at the same time and everybody is helping
[12:15] <siretart> \sh: hm. so you want to make people concentrating on one specific topic?
[12:15] <siretart> I just try to understand you
[12:15] <\sh> siretart: yes...in busy times like these days e.g.
[12:15] <ogra> siretart, that would be desirable, but happens anyway imho
[12:16] <bddebian> Please don't take this the wrong way but are there people concentrating on training new MOTU's?
[12:16] <\sh> ogra: but u have to see, like those merges now, if we would have this work in our eyes, we wouldn't be in a hurry and we wouldn't be in this situation far away from the timetable
[12:17] <crimsun> bddebian: we should all be assisting each other.
[12:17] <siretart> bddebian: let's discuss this later, ok?
[12:17] <ogra> bddebian, depending on your questions, yes
[12:17] <bddebian> siretart: ok
[12:17] <ogra> hey tseng 
[12:17] <tseng> hi
[12:17] <\sh> tseng: welcome
[12:17] <bddebian> welcome tseng 
[12:17] <dholbach> hey tseng :)
[12:17] <siretart> hey tseng, how are you?
[12:17] <ajmitch> morning tseng 
[12:17] <tseng> i will be just watching I think
[12:17] <dholbach> tseng: https://wiki.ubuntu.com/MOTUMeeting - first point
[12:17] <ogra> \hif everybody had looked at the merge stuff first, we wouldnt have had 250 pkgs there
[12:18] <dholbach> bddebian: i hope i'll be able to do more on this front in 4 weeks
[12:18] <ogra> \sh, even
[12:18] <dholbach> ogra: yes, that's why i suggest some leads organizing the different motu actions
[12:18] <bddebian> Like I said, don't take that the wrong way.  Everyone has been very helpful, I just don't see a specific "direction" so to speak.
[12:18] <\sh> ogra: that's what I meant...we had our eyes on something else as prio 1, and forget about those merges
[12:18] <ogra> dholbach, nope, its a process we must establish... 
[12:18] <ajmitch> ogra: yeah, I started doing some merges right at the beginning of the breezy cycle with my list
[12:19] <ajmitch> ogra: but quickly ran out of spare time
[12:19] <dholbach> ogra: a process like what?
[12:19] <\sh> ajmitch: so did I during the cxx trans
[12:19] <ogra> if you touch a package with -ubuntuX version you should always look for mergers first
[12:19] <comadreja> what about this as a middle point. Somebody dispatching tasks on a "do-it-if-you-can" way ?
[12:19] <siretart> \sh: the problem I have with this suggestion is, that I have different interests for breezy, and I try to accomplish them all. So focusing on one topic would mean choosing one topic I'd like to accomplish
[12:19] <ajmitch> ogra: that will reduce forking from debian
[12:19] <dholbach> ogra: ah ok yes
[12:19] <comadreja> like writing a wiki page 
[12:19] <ogra> dholbach, if we do the merges constantly, we dont have this many
[12:19] <dholbach> ogra: absolutely
[12:20] <dholbach> comadreja: you mean as in assigning jobs?
[12:20] <\sh> siretart: actually we all have "different" interessts ... I'm far from being finished with my projects I wanted to accomplish
[12:20] <ogra> ajmitch, yes, exactly... it will still be a fork, but the changes are smaller
[12:20] <crimsun> To be fair, though, several MOTUs have been busy otherwise (tritium, dholbach, and myself at least). As I see it, the problem isn't so much one of "we spent too much time doing non-merge stuff" but "we didn't have time at all".
[12:20] <comadreja> dholbach : like in writing in a wiki page a priority list
[12:20] <dholbach> comadreja: ah ok, i see
[12:20] <ajmitch> ogra: well we have to try & keep as close to debian as possible to avoid work for us
[12:20] <ajmitch> we have to be naturally lazy! ;)
[12:20] <\sh> crimsun: this is something u will always have for volunteer work
[12:21] <ogra> crimsun, did you look for every -ubuntuX package you touched at MOM first ? 
[12:21] <comadreja> that way, every single motu can use their time on that...
[12:21] <tseng> i dont like MOM
[12:21] <\sh> crimsun: even ogra is too busy to deal with motu stuff right now...
[12:21] <dholbach> \sh: do you think planning will be easier, if somebody signs up for such a task force?
[12:21] <crimsun> ogra: yep, that's how I've been getting back into the MOTU swing of things.
[12:21] <\sh> dholbach: I think it could help...some things are really showstopping us, right, and other things are just slipped out of our hands
[12:21] <ogra> crimsun, ah, great ten... i didnt and was hit by it...
[12:22] <ogra> s/ten/then
[12:22] <ogra> and many others of us too...
[12:22] <dholbach> who else thinks that a recruited taskforce will make planning easier?
[12:22] <bddebian> tseng: Agreed, it does have it's limitations
[12:22] <ogra> some packages from MOM were already touched in the Cxx transition for example
[12:22] <comadreja> dholbach : we first need a scheduler :)
[12:23] <dholbach> comadreja: of course, we need the plan first
[12:23] <comadreja> I'll join \sh
[12:23] <\sh> dholbach: if we have a fighting plan (for breezy+1), we know what transitions have to be done, on what we have to have a closer look (MoMs) etc. then we don't need a taskforce for those things
[12:23] <dholbach> to cap it up a bit: we agreed that we need more planning and maybe guys responsible for that, we too agreed, that we rely on volunteers work
[12:24] <dholbach> \sh: some things just happend and you can't foresee them, because you're not involved with libxyz's upstream
[12:24] <ogra> \sh, note, there will be no X and no Cxx transition...
[12:24] <siretart> \sh: Can you describe what you expect a taskforce to look like? what would be expected from ppl joining a taskforce? give an example
[12:24] <\sh> dholbach: things like Xorg yes..but this is ok..this will halt everything
[12:24] <ogra> breezy+1 will be an awesome development cycle
[12:24] <dholbach> yeah... let's get back to the TASK FORCE concept planning
[12:24] <\sh> ogra: we will have many bugs for breezy+1
[12:24] <ajmitch> breezy+1 is going to be different, in that main will be supported by the ubuntu foundation for *5* years
[12:25] <ajmitch> we need to try & get quality up
[12:25] <ogra> \sh, yes, but a lot less mass transitions and thus a lot more time to play and develop
[12:25] <ajmitch> ogra: more recruiting! :)
[12:25] <ogra> yay !
[12:26] <\sh> ogra: breezy+1 will be polishing our work now...breezy will  be a desert safari ,-)
[12:26] <\sh> ok...long story short...
[12:26] <dholbach> ok, who wants to make a suggestion that goes  beyond  "more organization"
[12:26] <bddebian> Then you need to either recruit folks that are familiar with hacking/Debian packaging or get some better direction for the NewMOTU process
[12:26] <ajmitch> bddebian: fine, put your suggestions down somewhere :)
[12:27] <siretart> ajmitch: I think I have an suggestion for NewMOTU process, more on this later..
[12:27] <dholbach> ok, as i see it there are 2 options
[12:27] <ajmitch> siretart: great
[12:27] <dholbach> 1) just try it out, whatever happens
[12:27] <\sh> ogra: u r involved in all that main stuff...I would like to take u as a "gateway" with main...to plan some important stuff to accomplish for breezy+1 so we can create something like a  "MOTU project plan"
[12:27] <dholbach> 2) flesh out the process for such a task forces with all it's implications and go from there again
[12:27] <crimsun> We could try each having a primary and a secondary "role", if you will. For instance, my primary role would be Mentoring new MOTUs, and my secondary would be Review work (aside from that done as part of mentoring). We could put this on our wiki pages.
[12:28] <\sh> ogra: just because u guys have a better overview what will come...and even 5 mins before it happens ,-)
[12:28] <ogra> \sh, sure, lets d that
[12:28] <ogra> do even
[12:29] <dholbach> ok... shall we put up wiki pages up for those ideas and decide over them again?
[12:29] <dholbach> this to me sounds like the best plan, since it is more detailed and more goal focused
[12:29] <siretart> dholbach: I second this suggestion. let's move on
[12:29] <ajmitch> yep
[12:29] <\sh> let's do it like that...
[12:29] <dholbach> \sh: thanks for bringing the point up - as you see - there are lot of opinions on that
[12:30] <dholbach> point two
[12:30] <siretart> but may I suggest some procedure for new MOTU's?
[12:30] <\sh> dholbach: yes...likley :) 
[12:30] <siretart> it is somehow related to that Team concept
[12:30] <dholbach> siretart: fire away
[12:30] <siretart> I propose a mentoring concept for newMOTU's
[12:30] <ogra> dholbach, why do we need to feed them, they give a grown up impression... they can gra it themselves
[12:31] <ogra> grab even
[12:31] <siretart> a bit similar to debian, but not quite. Each new candidate is assigned to one specific motu he uses as mentor
[12:31] <dholbach> ogra: siretart wanted to add a new team idea in between
[12:31] <tseng> eh
[12:31] <ogra> ah,oh, ok
[12:31] <tseng> people move really fast in motu right now
[12:31] <tseng> because they can get help from everyone
[12:31] <siretart> the apprentice and the motu aggree on a workflow how to get packages from the apprentice into universe
[12:31] <\sh> siretart: gentoo has this concept
[12:32] <siretart> this may or may not be using revu
[12:32] <ajmitch> tseng: they wouldn't be limited to this one person, but they'd be their primary contact
[12:32] <ajmitch> ogra: what's wrong with it?
[12:32] <siretart> \sh: I don't know how gentoo works, can you elaborate?
[12:32] <ajmitch> too much workload on existing motus?
[12:33] <dholbach> siretart: what i like about the current process is it's openness
[12:33] <ogra> it drags people more away into a secret corner... i see this with my google students, they arenot very active in the motu world, even if there are often people that could help them better then me
[12:33] <\sh> siretart: as u explained...when u want to get the dev status quo for gentoo, u need to have a mentor, which guides u through the whole infra structure and things like that, explains what is important in building ebuilds (in our case debian/*) etc.
[12:33] <dholbach> siretart: so more people have a good image of how a motu hopeful proceeds
[12:33] <tseng> ogra: right.
[12:33] <ogra> it tears down the amount of work done with the whole tem
[12:33] <ogra> team
[12:33] <siretart> ok. I see the point raised by dholbach and ogra.
[12:34] <dholbach> siretart: but this is a point we will have to discuss soon
[12:34] <dholbach> siretart: you were right in bringing this up
[12:34] <\sh> siretart: but the other devs don't know the "apprentice" at this time...and most of the times, the new devs will do whatever they want...
[12:34] <ajmitch> right, you don't want the big happy family to be dysfunctional
[12:34] <siretart> I don't want to take the newbees into secret corners. they should work with the community
[12:34] <siretart> the problem I want to solve is another one:
[12:34] <ajmitch> as the team grows, we don't want new MOTUs to get lost in the cracks
[12:34] <\sh> tseng: it's broken yes
[12:35] <siretart> having a mentor, an apprentice has a an advocate, which really know about the packaging skills of his apprentice
[12:35] <\sh> tseng: but it's not against gentoo..it's against their governance :(
[12:35] <dholbach> what do you think about this: shall a motu-process2 team sit together and throw some ideas together and form a "spec"?
[12:35] <siretart> so this mentoring concept is rather a more formal process of having packages sponsored
[12:35] <dholbach> over which we can decide more formally?
[12:35] <siretart> dholbach: perhaps this would be an idea.
[12:36] <dholbach> any other opinions?
[12:36] <ajmitch> dholbach: we might need to schedule another meeting soon then 
[12:36] <dholbach> yes
[12:36] <siretart> I'll try to write up my ideas on a wiki page and present them the next meeting
[12:36] <ajmitch> unless we do our debating on the wiki
[12:36] <dholbach> super, thanks siretart 
[12:36] <dholbach> it think it's better to have ideas more fleshed out, before we decide
[12:36] <siretart> this won't be before next week ;)
[12:37] <dholbach> may we get to point 2 now?
[12:37] <\sh> yes
[12:37] <ogra> siretart, we meet once a month ;)
[12:37] <ajmitch> please do..
[12:37] <ogra> take your time
[12:37] <dholbach> i proposed this one: "Proceedings of feeding UniverseNewPackages (and Andrew's RFP list) to utnubu-discuss."
[12:37] <dholbach> because i found that most of our NEW packages are not announced anywhere and just "end up in the archive"
[12:37] <dholbach> don't you think we should push them more into the debian direction?
[12:37] <ajmitch> dholbach: agreed, very important
[12:37] <ogra> why do we need to feed them, they give a grown up impression... they can grab it themselves lets just point them there
[12:38] <ajmitch> at the last meeting we resolved to file these RFPS
[12:38] <dholbach> there were only SOME reactions RFP/ITP-wise from our side
[12:38] <dholbach> ogra: yeah, but *nearly* nobody does it at the moment
[12:38] <ogra> ajmitch, now there is an active group in debian....
[12:38] <dholbach> so i think this should be more of a policy
[12:38] <ogra> dholbach, what ? 
[12:38] <ajmitch> ogra: I know, I see you're in the group
[12:38] <siretart> well, I don't think that it would be very much efford announcing new addition to universe to the utnubu mailing list
[12:38] <dholbach> that the package needs to be announced
[12:38] <\sh> ogra: u r involved in that utnubu thing
[12:38] <dholbach> siretart: ++
[12:39] <ajmitch> I've got to get involved there too
[12:39] <siretart> and I think nometa and other debian developers would really appreciate it
[12:39] <dholbach> \sh, ogra: yes?
[12:39] <\sh> ogra: how is the mood towards ubuntu patches and new packages at all?
[12:39] <ogra> dholbach, they have browsers eyes and are able to read... lets point them to the page and they can care themselves
[12:39] <luis_> could you create an rss feed from your current tools, and ask them to subscribe to that for timely/reliable info?
[12:39] <ogra> \sh, its ok... the tone is rougher...
[12:39] <ogra> luis_, sure
[12:39] <\sh> ogra: rougher? 
[12:40] <Seveas> luis_, there are RSS feeds for Ubuntu uploads
[12:40] <\sh> ogra: in what way?
[12:40] <siretart> \sh: I think it is generally very mixed and depends whom you ask. the utnubu guys seem to be very colaborative.
[12:40] <ogra> but my opinion is that we have enough work to do here... putting this stuff on a wiki page for them is already nice and makes their job easier
[12:40] <dholbach> i think it's no problem for anybody to write a mail: "hey, this is my package, it's in the archive, if you have questions, feel free to ask me"
[12:40] <ogra> but in the end its *their* job
[12:40] <dholbach> ogra: nobody does that either
[12:41] <\sh> actually, I can tell only about my experiences with some maintainers...
[12:41] <dholbach> an RSS feed in my opinion is not much of a "relationship", although it's convenient
[12:41] <\sh> and these exp. are really mixed
[12:41] <ogra> dholbach, i dont know since when youre subscribed to -utnubu-devel, but they already have tools to produce theur lists
[12:41] <siretart> dholbach: this could be the last step of work of the reviewing team, if a package is accepted into universe, write a small mail for that. I think I could hack something up like that for revu2..
[12:41] <dholbach> ogra: i read all the threads
[12:42] <dholbach> who is opposed to add "announce it on utnubu" to our MOTUNewPackagesPolicy?
[12:42] <ogra> dholbach, its their job as import team... its nice of us to offer them something, but i refuse to do their job
[12:42] <dholbach> ogra: we're not going to make them debian compliant or uploading or do whatever to the debian archive
[12:43] <comadreja> dholbach : I also think it's their job
[12:43] <dholbach> ok... any other opinions?
[12:43] <ogra> dholbach, if there are problems with a particular package i'm happy to help if they ask... but still they want to be the ubuntu import team...
[12:43] <dholbach> i never thought we'd have that response to writing a mail
[12:43] <\sh> ogra: can u give me the subscription address for this utnubu-devel ML? i only see -discuss and -maintainers
[12:43] <comadreja> dholbach : that mail could be automated
[12:44] <ogra> \sh, its on alioth.debian.org
[12:44] <ogra> \sh, search for utnubu
[12:44] <ogra> \sh, i meant -discuss above, sorry
[12:44] <\sh> ogra: ah ok :)
[12:45] <seb128> dholbach: don't annonce stuff on utnubu 
[12:45] <ajmitch> ogra: perhaps I should try & make it more part of my MOTU responsibilites then?
[12:45] <dholbach> ok... we seem to cannot agree here and will rely on volunteer action
[12:45] <dholbach> seb128: it think it's ok to announce a new package there - do you think that's a problem or might make us run into problems?
[12:45] <seb128> it's not ok
[12:45] <CarlFK> I didn't see anyone opposed to the rss feed idea
[12:45] <ogra> ajmitch, i dont see it as a motu responsibility... i see itas a responsibility to make the info public available, but thats all
[12:45] <seb128> this project is not fine
[12:46] <\sh> dholbach: I think with new packages not in debian they will come with RFP/ITP process...
[12:46] <dholbach> i think we can just offer
[12:46] <siretart> seb128: what are your objections to utnubu?
[12:46] <dholbach> ogra: i was talking about making info public available, nothing else :)
[12:46] <seb128> ie: I don't want somebody to just take GNOME stuff from Ubuntu, to put them on the utnubu SVN and non maintain them from here
[12:46] <seb128> Debian expects some quality
[12:47] <dholbach> but it might be a start of working together on stuff
[12:47] <seb128> if somebody wants to maintain a GNOME stuff with Debian he should rather work with pkg-gnome
[12:47] <ogra> dholbach, you were talking about announcing it to utnubu, which may end in endless discussions... i dont like to waste my time with that
[12:47] <siretart> seb128: I think that was not nometa's intention
[12:47] <seb128> ie: with people interesting on that
[12:47] <dholbach> ogra: announcing, not discussing details :)
[12:47] <seb128> s/interesting/interested/
[12:47] <ogra> dholbach, you end up with this... see gparted... i dont see the last word spoken there
[12:48] <seb128> dholbach: that's not the place to announce, stuff
[12:48] <seb128> they will grab them
[12:48] <dholbach> ogra: that's one case - you can't judge a project after 3-4 weeks
[12:48] <seb128> upload them here rather than at the right place
[12:48] <ogra> dholbach, nope, i know...
[12:48] <seb128> and non-maintain them
[12:49] <dholbach> ok, we had quite some interesting points here... :)
[12:49] <dholbach> ok, looking at the time, we might hop over to point 3 - is that ok for you?  
[12:49] <siretart> please
[12:49] <seb128> if somebody is interested to do the job for Debian he can do it correctly and join the appropriate team and working with thel
[12:49] <seb128> them
[12:49] <seb128> dholbach: go :)
[12:49] <dholbach> Trashing of MOTUNewPackages and MOTUToReview in favour of REVU
[12:49] <dholbach> the pages are momentarily just lying around
[12:50] <\sh> dholbach: when it's in the proper place on an own linode
[12:50] <dholbach> and nobody cares after them, some packages already got uploaded to REVU
[12:50] <dholbach> \sh: i'm solely talking about the wiki pages mentioned
[12:50] <\sh> I will clean them up...on sunday
[12:50] <\sh> dholbach: yes...
[12:51] <dholbach> \sh: we are discussing the point now :)
[12:51] <dholbach> does anybody feel we should keep them for a bit of time?
[12:51] <siretart> \sh: have you heard any news about the linode server?
[12:51] <\sh> siretart: no ... I will poke mdz or mako 
[12:51] <\sh> or jane?
[12:51] <dholbach> or elmo?
[12:51] <ogra> \sh, rather elmo
[12:51] <\sh> someone :)
[12:51] <\sh> or elmo
[12:51] <siretart> \sh: great. I haven't had time the last weeks. next week I think I will have more time to work on revu
[12:52] <dholbach> ok? anybody who wants to keep them to not annoy people who mentioned their package there?
[12:52] <siretart> I think I read that the common lisp team has packages for review there..
[12:52] <siretart> what about packages which are on the package, but not uploaded yet to revu?
[12:52] <\sh> what about this: <h1>THESE PAGES WILL BE REMOVED IN THE NEAR FUTURE</h1> <h2>Please upload your packages to REVU</h2> on the first two lines?
[12:53] <ogra> yep, thats there since a month
[12:53] <tseng> and email -devel
[12:53] <\sh> yep
[12:53] <dholbach> yeah, we maybe should do that
[12:53] <dholbach> keep them for a brief period of time
[12:53] <dholbach> and announce their disposal
[12:53] <dholbach> agreed
[12:53] <dholbach> robitaille: are you there? point 4 is your point :)
[12:53] <robitaille> yes I'm here.  
[12:54] <ajmitch> bug squashing!
[12:54] <dholbach> introduce us into the delights of malone assigning :)
[12:54] <robitaille> Should Malone bugs on Universe packages be assigned to MOTU members, or leave them unassigned?
[12:54] <ajmitch> as an aside, we should have a bug squashing party ;)
[12:54] <ajmitch> robitaille: assign them
[12:54] <robitaille> I have seen 2 positive feedback and one negative to the few I did recently
[12:55] <ajmitch> otherwise we don't see them
[12:55] <siretart> ++
[12:55] <tseng> i have no attention in even looking at bugs that are mass assigned to me
[12:55] <tseng> just one opinion
[12:55] <ogra> ajmitch, we have bugday every wednesday, since 2 months
[12:55] <dholbach> robitaille: i'm for it as well
[12:55] <tseng> i have my own bugs
[12:55] <ajmitch> tseng: you're different, in that you mainly focus on mono
[12:55] <tseng> yes.
[12:55] <ogra> ajmitch, tseng is on the teamlist
[12:55] <ajmitch> ogra: sure, but how often do people hear about that?
[12:55] <ogra> so he gets the bugmails
[12:55] <ajmitch> ogra: I know
[12:56] <\sh> well...we can assign them to the team and then can somebody pick up his favorite
[12:56] <ogra> ajmitch, you dont need to tell me that i suck as bugmaster ;)
[12:56] <dholbach> ok, how shall we deal with this?
[12:56] <robitaille> and there are maybe 250-300 bugs on universe packages.  THat's could be a lot of traffic
[12:56] <ajmitch> ogra: haha, I didn't mean that ;)
[12:56] <ogra> ajmitch, but i... i'd love to get rid of that job :)
[12:56] <ajmitch> ogra: search for willing victims :)
[12:56] <dholbach> ogra: can we add a mailing list for assigned bugs?
[12:57] <dholbach> ogra: so we don't annoy people with millions of bug mails
[12:57] <dholbach> ogra: i don't remember the last state
[12:57] <ogra> dholbach, why dilys is posting every new bug in #ubuntu-bugs
[12:57] <ogra> ajmitch, yes, i saw him too :)
[12:57] <dholbach> ogra: but i'm not on irc 24h
[12:57] <ajmitch> ogra: irc isn't the best place for bug notification
[12:57] <dholbach> ajmitch: ++
[12:57] <ajmitch> it's useful, for sure
[12:57] <ogra> ajmitch, dholbach dilys can be easily modified to feed to rss i guess
[12:58] <ajmitch> I've spotted bugs there & started on the fixing because of dilys
[12:58] <robitaille> I like the dilys announcements...a good way to do quick bug triage on the spot
[12:58] <dholbach> ok, how can we have MOTUs in the MOTU team (for visibility), but not annoy them with sometimes useless bug mails
[12:58] <ogra> since she already entertains us with her prose :)
[12:59] <dholbach> ok, don't we have a solution for that yet?
[12:59] <ogra> dholbach, thats a question  to the launchpad team
[12:59] <dholbach> a mailing list for motu bug mails would be cool
[12:59] <\sh> ogra: how fast can dilys be changed for feeding rss?
[12:59] <dholbach> ogra: i recall to already have asked the question - or maybe you did it
[12:59] <ogra> \sh, no idea... its not my baby
[12:59] <\sh> ajmitch: akregator ;)
[12:59] <ogra> dholbach, i think kiko said its trivial iirc
[12:59] <dholbach> ok
[01:00] <ajmitch> \sh: I said *decent* :)
[01:00] <dholbach> so we defer this question until we have a launchpad answer
[01:00] <\sh> ajmitch: ffox ;)
[01:00] <siretart> sistpoty: we need rss feeds for revu2 ;)
[01:00] <ajmitch> \sh: besides, I do a fair bit of work remotely
[01:00] <dholbach> is that ok with you?
[01:00] <\sh> sistpoty: rss2 please with full comments ;)
[01:00] <sistpoty> siretart: ack ;)
[01:00] <ogra> dholbach, yep... o with me...
[01:00] <ogra> ok
[01:00] <dholbach> ok
[01:00] <dholbach> common REVU practices - there are two topics I can think of, which got discussed on REVU - maybe we should have a bit of bendable policy and an agreement here
[01:00] <dholbach> 1)  config.{guess,sub} in the diff (relying on build hosts' build system vs. clean diff)
[01:01] <dholbach> 2)  changing .ORIG.tar.gz (sorry, I'm a bit biased)
[01:01] <dholbach> :)
[01:01] <\sh> aehm
[01:01] <dholbach> opinions on how to deal with that kind of stuff :)
[01:01] <\sh> 1) i don't like copies of config.{guess,sub} in the clean targets of the rules...
[01:01] <ogra> i thinkwe should hear a very experienced package for 1)
[01:01] <ogra> packager even
[01:02] <siretart> ajmitch: how do you think about this topic, with your DD hat on ;)
[01:02] <\sh> they're messing sometimes the who diff.gz so I put them in the configure target before ./configure
[01:02] <bddebian> heh
[01:02] <Riddell> \sh: you mean removing copies in the clear targets?
[01:02] <ajmitch> siretart: I've been a MOTU longer than a DD ;)
[01:02] <\sh> Riddell: yep
[01:02] <siretart> hehe
[01:03] <\sh> or the build management is so intelligent to remove those diffs from diff.gz
[01:03] <ajmitch> but I don't like having a diff with that mess
[01:03] <\sh> Riddell: and putting them in the configure target or config.sub
[01:03] <dholbach> i think there is clearly clearability of the diff  versus  relying on build systems' config.{guess,sub}
[01:04] <dholbach> (and we're talking about two files)
[01:04] <Riddell> \sh: what's wrong with removing it in debian/rules clean?
[01:04] <siretart> I see general agreement leaving config.{guess,sub} out for nicer .diff.gz (and therefore, better reviewability)
[01:04] <ogra> Riddell, its about *adding* it there
[01:04] <tseng> thats a pet peeve of mine
[01:04] <tseng> i cant stand that stuff in the diff
[01:05] <\sh> Riddell: dh_make templates is not removing them in debian/rules clean, they're copying it from build system
[01:05] <\sh> Riddell: so the diff.gz or debdiffs are getting messy with this crap
[01:05] <tseng> hi mdz :)
[01:05] <\sh> Riddell: it you move it from clean target to configure target u won't see them in the diff.gz or debdiff
[01:06] <mdz> I can't be fully attentive but if you have specific questions I can try to answer
[01:06] <dholbach> we're trying to arrange a bendable agreement on point 5 of https://wiki.ubuntu.com/MOTUMeeting
[01:06] <dholbach>  config.{guess,sub} in the diff (relying on build hosts' build system vs. clean diff)     and      changing .ORIG.tar.gz
[01:06] <siretart> mdz: the current topic is if config.{guess,sub} should be deleted in debian/rules clean target
[01:07] <dholbach> because the reviewers suggested different "solutions"
[01:07] <mdz> I am not a fan of updating those files during the build in the first place
[01:07] <ogra> by default dh_make places the copying of these files in the clean target, that means i clutter my diff.gz totally... whats the rationale for that
[01:07] <dholbach> be back in a minute
[01:07] <Riddell> \sh: so move the  rm -f config.{guess,sub} from debian/rules clean to debian/rules configure?  how it that more elegant?
[01:08] <\sh> Riddell: it's not about rm -f config.{guess,sub} it's about cp -f /usr/share/misc/config.{guess,sub} $(CURDIR) in clean target
[01:08] <ogra> Riddell, its the cp that puts them into your sourcetree, not the rm....
[01:09] <seb128> just use cdbs :p
[01:09] <ajmitch> seb128: sadly we can't convert the world to cdbs :)
[01:09] <bddebian> Why not? ;-)
[01:09] <mdz> doing a build and then cleaning the tree should give you back the same tree you started with
[01:10] <ogra> it is done in the clean target by default, while it could be done with a build-dep on autotools-dev which makes sure the fils are the most recent and saves space in the diff
[01:10] <ajmitch> mdz: isn't that part of the automated testing spec?
[01:10] <dholbach> the readability isnt such a big point when you're talking about two files, is it?
[01:10] <mdz> ajmitch: possibly?
[01:11] <mdz> so if 1) you are updating config.* during the build, and 2) the build is being done in-tree, then you need to restore the files, not delete them
[01:11] <ogra> dholbach, if you make only a dependency change the difference is *huge*
[01:11] <ajmitch> I think pitti was talking about that, but that's another matter
[01:11] <mdz> that is what cdbs does, I believe
[01:12] <dholbach> ogra: and you rely on the build system's config.{sub,guess}, which is the whole point of copying them in before, NOT relying on the build system, but on your patch
[01:12] <siretart> so the approach dh_make uses is broken?
[01:12] <mdz> dh_make is broken in all sorts of ways
[01:12] <sistpoty> siretart: i think so... at least the templates that come from it (iirc)
[01:12] <\sh> ok...
[01:13] <\sh> this is an example
[01:13] <ogra> dholbach, but since they carry the descriptions of supported arches etc, i dont see the point not to take them from the build system... they'll match the build system... and in my eyes they are part of the tools, not of the source
[01:13] <\sh>         -test -r /usr/share/misc/config.sub && \
[01:13] <\sh>           cp -f /usr/share/misc/config.sub config.sub
[01:13] <\sh>         -test -r /usr/share/misc/config.guess && \
[01:13] <\sh>           cp -f /usr/share/misc/config.guess config.guess
[01:13] <\sh> in clean target before dh_clean
[01:14] <dholbach> shall we take this question to the mailing list and proceed to the next one? :)
[01:14] <\sh> so debuild is calling debian/rules clean first, copies the build systems config.{guess,sub} to the $(CURDIR) and messes the diff..this is what dh_make gives u as template...and many packages are using it
[01:14] <dholbach> oh sorry, \sh wanted to say something
[01:15] <\sh> example: atlas-cpp
[01:15] <dholbach> \sh: it doesnt "mess" for the sake of it
[01:15] <siretart> from the discussions we had, I'd consider that pattern in debian/rules broken
[01:15] <ajmitch> \sh: right, cdbs has a fair bit of stuff in /usr/share/cdbs/1/rules/buildcore.mk & other files for handling this
[01:15] <ogra> me too
[01:15] <dholbach> \sh: it's there for a good reason - even lintian complains about too old config.{guess,sub} for a reason
[01:15] <siretart> it fails to restore the package state
[01:16] <ogra> dholbach, but it describes the capabilitys of the build tools, so why not use the ones from the actual build system
[01:16] <\sh> dholbach: i don't mind to copy that stuff..but not in the clean target, cause the diff is generated after debian/rules clean 
[01:16] <dholbach> \sh: if you copy it in, it will always be in the diff
[01:17] <ogra> dholbach, it will be always new in every diff...
[01:17] <\sh> dholbach: not if the tree is cleaned correctly...it copies the stuff only, when config.{guess,sub} is not in place
[01:17] <ogra> dholbach, which is a total waste
[01:17] <seb128> these file are updated because that's required to build on some archs
[01:17] <\sh> but it's build time..not cleaning time...
[01:18] <dholbach> (especially for all those packages in debian that weren't touched for like two decades.... :))
[01:18] <\sh> so it should be in those parts where the build is done..and not where the build stuff is cleaned up
[01:18] <dholbach> but then you don't have control over what you upload, you rely on the build hosts config.{sub,guess}
[01:18] <ogra> seb128, yes, but why not updating them on the actual build system they use... i.e. at buildtime...
[01:19] <seb128> that's what cdbs does
[01:19] <seb128> dholbach: you don't want to use your version, autotools-dev has the reference versions known to work
[01:19] <\sh> seb128: that's what I said...put this piece of code in debian/rules configure target before the ./configure call...
[01:19] <ogra> ah, so my doing isnt wrong then :)
[01:20] <ajmitch> ogra: no, that's what we're arguing about ;)
[01:20] <mdz> the best solution would be to modify autoconf, upstream, to use the newer of the installed file and the one shipped with the package
[01:20] <dholbach> seb128: i want to use the version, i have locally on my disk, which procudes my diff :)
[01:20] <mdz> then this problem goes away entirely
[01:20] <seb128> dholbach: why? 
[01:20] <mdz> it's the way it should have worked in the first place
[01:20] <ogra> dholbach, that might be outdated at buildtime...
[01:21] <mdz> I suggest proposing that to the upstream maintainer with a description of our situation
[01:21] <ogra> ok...
[01:21] <dholbach> mdz: which upstream?
[01:21] <dholbach> mdz: every single one of each package?
[01:21] <ogra> any objections when we go on to use the ones on the buildd until thats fixed ?
[01:22] <mdz> dholbach: autoconf upstream, as I said
[01:22] <dholbach> mdz: ah ok
[01:22] <dholbach> mdz: thanks
[01:23] <dholbach> ok, seems like we should proceed to the next time :)
[01:23] <bddebian> Are we making any decisions? ;-)
[01:23] <dholbach> what do you all think about chaging orig.tar.gz?
[01:23] <ogra> bddebian, thats rare in motu meetings... 
[01:23] <ajmitch> dholbach: I don't like it
[01:23] <ogra> ;)
[01:23] <ogra> me neither
[01:24] <\sh> bddebian: yes we're contacting the autotools (god) upstream maintainer ;)
[01:24] <ajmitch> dholbach: and it should only be done where really really necessary
[01:24] <seb128> don't touch the orig.tar.gz
[01:24] <dholbach> i know cases of packaging cvs exported stuff, where a ./autogen.sh && make dist is in order
[01:24] <ajmitch> exceptions are license issues, where you have to cut out undistributable source
[01:24] <dholbach> but that's all i'd allow policy-wise
[01:25] <ogra> seb128, what do you do with cvs checked out stuff... dont you remove the CVS dirs ?
[01:25] <\sh> dholbach: why don't u call ./autogen during build time? ,-)
[01:25] <dholbach> ogra: cvs export
[01:25] <ajmitch> ogra: do that in debian/rules
[01:25] <dholbach> \sh: you don't do that :)
[01:25] <seb128> ogra: I use "make dist" which makes a proper tarball
[01:25] <Riddell> changing .orig.tar.gz is fine for removing upstream debian/ directories
[01:25] <seb128> no
[01:25] <\sh> dholbach: for cvs stuff of course...cause the original tarball is cvs exported...
[01:26] <siretart> debian policy suggests the target get-orig-source
[01:26] <siretart> This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory.
[01:26] <seb128> replacing the debian/ dir can go to the diff.gz
[01:26] <dholbach> seb128: ++ even if it looks ugly
[01:26] <seb128> it's not ugly
[01:26] <dholbach> seb128: in the diff - and i don't care about that :)
[01:27] <dholbach> seb128: i'm not opposing
[01:27] <seb128> k :)
[01:27] <seb128> -- other way :p
[01:27] <dholbach> but it's very hard to check hwo the source was altered
[01:27] <dholbach> and i ALWAYS do that when reviewing packages
[01:27] <dholbach> and you should imho do that too
[01:27] <ajmitch> my debian sponsor told me off for repacking the orig tarball :)
[01:27] <ogra> dholbach, please... indeed everybody does that :)
[01:27] <dholbach> in that perspective chainging orig.tar.gz is not very nice
[01:28] <dholbach> ogra: yes?
[01:28] <ogra> dholbach, sure... at least every reviewer i know around here
[01:28] <Riddell> I've also had tar files which are badly made upstream and arn't distcleaned, that should be tidied for .orig.tar.gz in my opinion
[01:28] <dholbach> ogra: i never did see such a comment on REVU expept my own :)
[01:29] <ogra> dholbach, you need to be more around on IRC ;-p
[01:29] <ajmitch> there is the other exception - cdbs & tarball.mk
[01:29] <seb128> if upstream tarball is not nice speak with upstream to get that fixed
[01:29] <dholbach> Riddell: i think it's more important to lart upstream and get it fixed in the diff :)
[01:29] <\sh> the question is, when you generate a CVS/SVN snapshot..is it a real orig.tar.gz or should we handle it in some other way
[01:29] <tseng> \sh: look at evolution-sharp
[01:29] <seb128> dholbach: exactly :)
[01:29] <tseng> evolution-sharp_0.6.99+0.7.orig.tar.gz
[01:30] <\sh> tseng: u made a diff from 0.699 to 0.7...
[01:30] <dholbach> siretart: i never heard of that target before - i'll have a look into it, thanks for the pointer
[01:30] <\sh> ?
[01:30] <tseng> no, i made a snapshot of the 0.7 branch
[01:31] <siretart> dholbach: it is an optinal target, though. But mentioned in debian policy, so I'd consider that as semi official target
[01:31] <\sh> tseng: and u called autogen.sh and created your own tarball?
[01:31] <dholbach> siretart: i'll look into it :)
[01:31] <tseng> autogen and make dist
[01:31] <ajmitch> \sh: that's a standard way to do it
[01:31] <ajmitch> \sh: since there is no existing tarball
[01:31] <siretart> dholbach: section 4.8
[01:31] <dholbach> cvs exports are an exceptional case i think
[01:31] <ogra> dholbach, isnt that what the debian/watch file is for ?
[01:31] <Riddell> I also change .orig from tar when using unsermake but upstream has made the tar for automake
[01:32] <seb128> all the changes can go to the diff.gz
[01:32] <Riddell> seb128: that makes for a muckle .diff.gz
[01:32] <ogra> seb128, s/can/should
[01:33] <dholbach> who took notes for PackagingTips?
[01:33] <ajmitch> ok, so do we have any agreement here?
[01:33] <Riddell> and some changes can't go in .diff e.g. removing files
[01:33] <ogra> Riddell, sure they can
[01:33] <\sh> too many ways are leading to mekkah
[01:34] <Riddell> ogra: removing files can't, means you need to add explicit rm -f  lines to debian/rules
[01:34] <bddebian> heh
[01:34] <ogra> ajmitch, bah, youre just volunteering for a review day master job and cant wait... be patient !
[01:34] <dholbach> i think it's crucial, to encourage new motus to work tidily, to just grab upstream's tarball, apply their changes to it and not let them rip out what they want to make something "easier"
[01:34] <ogra> Riddell, and ? 
[01:35] <Riddell> tidier and less error prone to just fix the upstream tar for the .orig
[01:35] <siretart> sorry folks, I need to leave now. See you tomorrow
[01:35] <\sh> cu siretart 
[01:35] <bddebian> Later siretart 
[01:36] <sistpoty> gn8 siretart
[01:36] <ajmitch> ogra: oh sure, it's my wildest dream ;)
[01:36] <ogra> ;)
[01:37] <dholbach> the problem as i see it, is: it's harder to track what people did to the code, people from other distributions/other developers have no clue, what they did to upstreams code, in my eyes it might even lead to security - imagine a new motu uploading a "modified" upstream source - you'd just read .diff.gz and not recognize what happened
[01:37] <ogra> Riddell, but breaking a holy rule :)
[01:37] <\sh> dholbach: changing upstreams code only via patch in debian/rules patch 
[01:37] <dholbach> bye siretart 
[01:37] <seb128> dholbach: md5sum should match upstream one
[01:37] <ajmitch> dholbach: I agree, someone reviewing should ideally be able to grab the tarball off upstream's site, confirm md5sum is what you have, and use it
[01:37] <dholbach> \sh: that's what we're talking about
[01:38] <tseng> im not sure why we even need to talk about this :)
[01:38] <dholbach> seb128: that's what i'm saying: never change the upstream orig.tar.gz :)
[01:38] <tseng> it seems obvious.
[01:38] <dholbach> ajmitch: that's what i do
[01:38] <ajmitch> tseng: it is obvious, but not everyone does it
[01:38] <\sh> dholbach: but this is the rule ;) 
[01:38] <dholbach> ok, then we can all agree on pushing people to lart upstream, if the code/buildsystem is buggy and fix it in .diff.gz, right?
[01:38] <seb128> yep
[01:39] <dholbach> super
[01:39] <tseng> ++
[01:39] <dholbach> i love you guys
[01:39] <dholbach> last point on the agenda
[01:39] <dholbach> ajmitch: do it! :)
[01:39] <dholbach> seb128: :))))
[01:39] <\sh> dholbach: this is what we're doing all the time..fixing stuff from upstream via patch/dpatc
[01:39] <\sh> h
[01:39] <ajmitch> dholbach: why me? ;)
[01:39] <ogra> yeah, ajmitch for REVIEW MASTER !!
[01:39] <dholbach> ajmitch: it's your point
[01:40] <bddebian> ++
[01:40] <ajmitch> ok, I'm not applying for ReviewMaster, but we need to review *more*! :)
[01:40] <Riddell> dholbach: I trust you'll inform debian's ftpmasters of that policy then
[01:40] <\sh> ajmitch: come on...push us ,-) 
[01:40] <ogra> ajmitch, to late... you got the job now :)
[01:40] <ajmitch> dholbach's enthusiasm for review days is great
[01:40] <ajmitch> so I think they need to be a regular part of our calendar
[01:40] <ajmitch> and we need to keep the list as short as possible
[01:41] <ajmitch> of course, feel free to do reviewing at anytime you can
[01:41] <ogra> ajmitch, dholbach will soon have a new job that draws his time.... dont expect him to be much more active then me
[01:41] <ogra> (in motu land)
[01:41] <dholbach> Riddell: i think we established reasons for doing it that way
[01:41] <ajmitch> ogra: yeah, don't expect anyone here to have lots of free time
[01:41] <ogra> ajmitch, and since you brought it up .... :)
[01:41] <ogra> ajmitch, i dont ...
[01:41] <ajmitch> looks like I've got another cap then?
[01:42] <dholbach> ogra: you seem to know more than i do
[01:42] <ajmitch> dholbach: sure, you'll probably find out about your job responsibilities the day you start (or later) :)
[01:42] <dholbach> i always had review days in mind like a measure to catch up on the always growing lists
[01:42] <\sh> ok...last point now...last cigarette
[01:42] <ogra> dholbach, just guessing from experience
[01:42] <ogra> ;)
[01:42] <dholbach> \sh: i have no papers left
[01:42] <ogra> dholbach, next meeting date and time
[01:43] <ajmitch> review days are a good time to make sure that the new guys are around to talk to
[01:43] <dholbach> i hope we'll find a way to get them sorted soon
[01:43] <dholbach> ajmitch: yeah that's true
[01:43] <ajmitch> ogra: 2 weeks or 4?
[01:43] <dholbach> ok... when will be next 1) review day 2) motu meeting?
[01:43] <ogra> we had said 4 once
[01:43] <\sh> ogra: between the last one and now were only 2 ;)
[01:43] <ogra> but if itsrewuired, we should change it
[01:43] <ajmitch> dholbach: next review day in 2 weeks
[01:43] <\sh> as I remember
[01:44] <ogra> \sh, the last one was postponed 2 weeks
[01:44] <ogra> so it were actually 6
[01:44] <ajmitch> by 'day' we mean a 48-hour period or more :)
[01:44] <dholbach> ajmitch: ok, i'll do an announce - august 18th?
[01:44] <\sh> ogra: oh yes
[01:44] <ajmitch> dholbach: sounds good
[01:44] <dholbach> ok, next review day august 18th
[01:44] <\sh> 2.9 + 14 days?
[01:44] <ogra> dholbach, calendar ? 
[01:44] <dholbach> next motu meeting when?
[01:44] <\sh> 16
[01:44] <\sh> fits
[01:44] <dholbach> ogra: i'll do it
[01:44] <ogra> great...
[01:45] <dholbach> so when will it be?
[01:45] <dholbach> which time?
[01:45] <dholbach> the motu meeting
[01:45] <ogra> this current meeting isnt mentioned... we are lost without your care dholbach 
[01:45] <ajmitch> dholbach: 3 weeks? :)
[01:45] <ajmitch> does this time of day suit people?
[01:45] <dholbach> a bit earlier :)
[01:46] <ajmitch> ok
[01:46] <dholbach> ogra: it is
[01:46] <ogra> iwouldnt say it suits, but better then 6:00 UTC 
[01:46] <ajmitch> 20:00 UTC?
[01:46] <bddebian> Aye
[01:46] <bddebian> ajmitch: 20:00 is good
[01:46] <dholbach> yeah
[01:46] <ajmitch> great
[01:46] <comadreja> ++
[01:46] <dholbach> which date?
[01:46] <ajmitch> 8am for me, not too hard :)
[01:46] <ogra> dholbach, since when, i imported the calendar yesterday 
[01:46] <ajmitch> dholbach: 3 weeks from now is the 24th
[01:46] <ajmitch> if you want it that soon
[01:47] <ajmitch> we've got a few things for the agenda already
[01:47] <dholbach> ok
[01:47] <ogra> dholbach, haha... 4th 00:00 *g* its there since ~2h it seems, sorry for the noise
[01:47] <dholbach> ogra: 3rd 22:00 utc
[01:48] <ogra> dholbach, my evo translates the TZ to localtime :)
[01:48] <dholbach> ah ok
[01:48] <dholbach> ok
[01:48] <ogra> so it shows up for the 4th
[01:48] <dholbach> one last thing: who will do a quick wrap up for the mailing lists?
[01:48] <dholbach> a quick one
[01:48] <ogra> i already missed the last one...
[01:48] <dholbach> i won't have the time this time
[01:49] <ogra> me neither 11th is feature freeze
[01:49] <\sh> bddebian will do it ,-)
[01:49] <dholbach> i'll do the announces of the next meetings/review days - thanks everybody - you guys rock! :)
[01:49] <ajmitch> dholbach: great, thanks
[01:49] <bddebian> \sh: Sure pretty easy.  "No decisions were made"
[01:49] <ogra> bddebian, volunteering to write a wrap up ? 
[01:49] <ajmitch> so who will summarise? bddebian, or shall I volunteer? :)
[01:49] <\sh> bddebian: ;) http://people.ubuntu.com/~fabbione/irclogs/
[01:49] <ogra> bddebian, thanks :)
[01:50] <dholbach> just describe the points on the agenda and 2 sentences on what we decided/discussed :)
[01:50] <ajmitch> looks like it's been decided for poor bddebian 
[01:50] <bddebian> Aye, wtf? :-)
[01:50] <ajmitch> bddebian: I can do it if you prefer
[01:50] <ajmitch> but it will take a couple of days for me to get to
[01:50] <\sh> bddebian: actually u r a native speaker...so when I will write all this...damn my english teacher will kill me ,-)
[01:50] <dholbach> good night :)
[01:51] <ajmitch> night dholbach 
[01:51] <\sh> ajmitch: let bddebian do it ;)
[01:51] <bddebian> ajmitch: I wouldn't mind but between not being an MOTU nor being on the ML, maybe you should?
[01:51] <bddebian> gnight dholbach 
[01:51] <sistpoty> night dholbach
[01:51] <\sh> bddebian: u will write...and I will post
[01:51] <comadreja> nite
[01:51] <\sh> cu guys...
[01:51] <ogra> ciao dholbach 
[01:51] <\sh> good night even :)
[01:51] <mbreit> good night...
[01:51] <\sh> bddebian: deal?
[01:52] <bddebian> \sh: deal
[01:52] <\sh> bddebian: ok :)
[01:52] <ajmitch> alright..
[01:52] <ogra> bddebian, http://lists.ubuntu.com/archives/ubuntu-devel/2005-March/005093.html
[01:53] <bddebian> Can I hit it tomorrow morning, my time?
[01:53] <\sh> bddebian: and u'll find the logs of this meeting on http://people.ubuntu.com/~fabbione/irclogs/ so u know what to summarize
[01:53] <\sh> bddebian: yes
[01:53] <ogra> bddebian, you can hit it every time you like...
[01:53] <bddebian> heh
[01:53] <sistpoty> gn8 everybody
[01:53] <bddebian> gnight sistpoty 
[01:53] <ajmitch> night sistpoty 
[01:53] <bddebian> Go to bed :-)
[01:54] <\sh> will do right now :)
[01:54] <bddebian> I gotta go play with the kids, catch you all later
[01:54] <bddebian> ajmitch: Have fun :-)
[01:54] <ogra> ciao bddebian and thanks :)
[01:54] <\sh> bddebian: play soccer ;)
[01:54] <bddebian> ogra: np
[01:54] <\sh> ok...good night gentlemen :) cu later this morning ;)
[01:54] <bddebian> \sh: Aye :)
[01:54] <bddebian> gnight \sh
[01:54] <ogra> \sh, sleep well
[01:54] <\sh> trying to :)
[01:54] <ajmitch> someone can put the next meeting & review days on the calendar?
[01:55] <janimonoses> good night all
[01:56] <ajmitch> hmm, will do after lunch, someone remind me then :)
[01:56] <robitaille> ajmitch: I can do it a bit later when I update my ics file
[01:56] <ogra> ajmitch, dholbach said he would 
[01:56] <ajmitch> robitaille: dholbach has it open for editing
[01:56] <ajmitch> so I'll leave that to him
[01:57] <robitaille> these daniels are so good at updates... :)
[01:57] <ogra> heh
[01:57] <ogra> what would we dou without you :)
[01:57] <ogra> s/dou/so
[01:57] <ogra> do
[01:57] <ogra> grrrr
[01:58] <cyphase> hey everyon
[01:59] <cyphase> everyone*
[01:59] <ajmitch> hello
[02:00] <ajmitch> bye all
[02:01] <robitaille> cyphase:  looking for a meeting?
[02:05] <Seveas> robitaille, this isn't a dating channel ;)
[02:08] <tseng> its not?