[01:25] <ranf> @now
[01:26] <Hobbsee> ranf: 30 mins
[01:33] <ranf> Hobbsee, k thanks
[01:56] <dholbach> siretart: do you know if sistpoty is going to turn up for the meeting?
[01:56] <dholbach> the first agenda item is his, but I reckon it's of an old agenda - I remember we discussed this at least twice before
[01:57] <ajmitch> charter?
[01:57] <dholbach> yes
[01:57] <siretart> dholbach: I haven't seen him today, but I know he's starting his new job next week (I think on monday)
[01:58] <dholbach> alright
[01:58] <dholbach> StevenK: we're 100 in the channel already :)
[01:59] <StevenK> ajmitch: Surely we're more interesting?
[02:00] <ajmitch> StevenK: "no, not in the slightest"
[02:00] <dholbach> ok, let's get started
[02:00] <dholbach> agenda is at https://wiki.ubuntu.com/MOTU/Meetings
[02:00] <dholbach> ScottK wanted us to agree on a policy for something like clamav backports
[02:01] <ScottK> dholbach: Want me to start the discussion then?
[02:01] <dholbach> yes
[02:01] <ScottK> The current problem is that the clamav 0.90 versions cannot be directly backported because they break stuff that depends on them
[02:02] <ScottK> but the current packages have outstanding security issues that no one has stepped up to fix.
[02:02] <dholbach> how does stuff break?
[02:02] <minghua> anything we can take from volatile.debian.org?
[02:02] <ScottK> Going from 0.8x to 0.9x some of the interfaces changed
[02:02] <dholbach> or how would a fix look like?
[02:02] <dholbach> right, so it's some kind of library transition?
[02:02] <ScottK> Yes
[02:03] <ScottK> Additionally, the lib went from libclamav1 to libclamav2
[02:03] <Hobbsee> dholbach: means that klamav doesnt start / crashes / etc, and other related programs, which are binary incompatible with 0.8 & 0.9
[02:03] <StevenK> I'm also guessing that ClamAV break ABI compatibility without bumping their SOVER?
[02:03] <minghua> I think I remember, volatile.debian.org updated clamav as well as all packages that depend on it
[02:03] <dholbach> the problem with backports is that we can't upload directly to it and stuff is synced (if I understand it correctly)
[02:03] <ScottK> The problem is that there are a LOT of redepends.
[02:03] <ScottK> redepends/rdepends
[02:04] <StevenK> minghua: Yes, but volatile is completly seperate. I can't see feisty-volatile getting created just for ClamvAV and friends.
[02:04] <ScottK> And so ugrading all the stuff that might break is, I think, a non-starter
[02:04] <Fujitsu> I think we are able to modify stuff now, dholbach.
[02:04] <StevenK> Although, PPA might be a way around this.
[02:04] <Hobbsee> (18)
[02:04] <Fujitsu> Or we were meant to be able to soon.
[02:04] <dholbach> 13 source packages if I counted correctly
[02:04] <Hobbsee> dholbach: sounds about right, i was counting binaries
[02:05] <dholbach> I think it might make sense to look into how much effort fixes are
[02:05] <StevenK> I think we're going to have to deal with the rdepends anyway. They will break/need dealing with no matter what path we take.
[02:05] <dholbach> I can't imagine that all library calls have been changed completely
[02:05] <ScottK> In thinking about this, I thought about something like separate repo for clamav and it's redepends, but that just seemed to hard
[02:05] <siretart> dholbach: we DO can upload directly to -backports
[02:05] <dholbach> siretart: ok, good to know
[02:05] <ScottK> The latest proposal I made on what to do is here https://lists.ubuntu.com/archives/ubuntu-motu/2007-May/001649.html
[02:05] <siretart> dholbach: the upload will be pocketed, and pitti asked to be notified about that case
[02:06] <siretart> or better the archive-admins in general
[02:06] <dholbach> siretart: I asked because I wasn't sure if it makes sense to backport complete new upstream versions (which might need other stuff)
[02:06] <ScottK> dholbach: No one has stepped up to maintain the current versions and so I think it's a choice between the new upstream versions and nothing.
[02:07] <dholbach> ScottK: what would be built against clamav-alt?
[02:07] <Hobbsee> i really dont think we can give users a credible experience of clamav, with the old, buggy version
[02:07] <StevenK> I agree.
[02:07] <Hobbsee> particularly as servers probably use virus scanners and such, like clamav and friends
[02:07] <dholbach> Hobbsee: I think we all agreed that it's a problem we need to deal with. :-)
[02:07] <siretart> what about having the clamav backport in a PPA until we consider them 'mature', and then sync them to -backports?
[02:07] <StevenK> And users might well get confused if say, klamav doesn't get fixed to use clamav-alt ...
[02:08] <Hobbsee> if anything, these are the sorts of packages we need to update for LTS, and be exempt from the "no updates" rule
[02:08] <dholbach> Would somebody volunteer to check how much changed in the library interfaces?
[02:08] <ScottK> I think an important part of the proposal is to gather a team of end users to test this stuff and then have a wiki about what breaks and what doesn't.
[02:08] <StevenK> Bugs aplenty about how klamav uses an old clamav.
[02:08] <dholbach> ScottK: team++
[02:08] <Hobbsee> dholbach: plenty of impressive dupes over how klamav was utterly *stuffed* with the new clamav
[02:08] <dholbach> Hobbsee: I can imagine
[02:09] <ScottK> At least klamav runs.  Clamtk is utterly hopeless right now.
[02:09] <dholbach> my proposal is: check what changed in the library interfaces, hope that it's not that much, patch the apps to work with libclamav2, upload all the stuff to -proposed, then to -updates
[02:09] <Hobbsee> you'd have to build all of the rdepends against clamav-alt, i guess.
[02:09] <dholbach> maybe I don't understand it correctly, but I don't see what clamav-alt would gain us
[02:10] <dholbach> given that we need to rebuild stuff against it anyways
[02:10] <Hobbsee> dholbach: twitch.  is anyone *seriously* that dedicated to these packages to maintained an upstream delta, which they had to do security fixes for?
[02:10] <Hobbsee> true
[02:10] <StevenK> But clamav-alt would require changes.
[02:10] <Hobbsee> i'd partially be in favour of just doing clamav with a security update, or something
[02:10] <StevenK> A rebuild requires a debian/changelog change.
[02:10] <ScottK> dholbach: The idea would be to enable people to knowingly install the latest clamav and accept the risk.
[02:10] <Hobbsee> is there really a use case for the old clamav, without security fixes?
[02:10] <dholbach> ScottK: but if stuff is not built against it (and changed it need be), nothing will use it
[02:11] <StevenK> Hobbsee: It's known stable? :-P
[02:11] <ScottK> There are things that just work.  From the limited testing I've does, I think stuff that uses clamd is fine
[02:11] <ScottK> does/done
[02:11] <dholbach> What about this: get a team of people interested in clamav together and research which package needs which kind of work
[02:11] <dholbach> it should be easier to go from there when we have the information
[02:12] <ScottK> What underlies this issue is the different needs for desktop and server.
[02:12] <dholbach> at the moment I feel that a lot of guessing is involved
[02:12] <minghua> I have a question, are we trying to fix this for dapper only, or dapper, edgy and feisty?
[02:12] <Hobbsee> minghua: feisty got fixed - it got a UVFe for all of it, i think
[02:12] <dholbach> minghua: best to have a general solution
[02:12] <Hobbsee> minghua: klamav certainly did
[02:12] <ScottK> If all we cared about was servers and clamd, then it'd backport OK.
[02:12] <StevenK> This will come up for feisty at some point, I daresay.
[02:12] <ScottK> clamav and klamav are current in Feisty.
[02:12] <StevenK> The reason it hasn't yet is because it was released last month.
[02:13] <minghua> I am just thinking backporting for all three releases would increase the work quite a bit
[02:13] <ScottK> At the very least I think that Dapper MUST be addressed.
[02:13] <StevenK> I agree.
[02:13] <Fujitsu> Edgy is unimportant, IMO
[02:13] <dholbach> who would join the team and investigate in how big the changes are?
[02:13] <StevenK> Even if we just say we're fixing clamav for the LTS release, and complaining Edgy users can upgrade.
[02:13] <dholbach> if we do dapper, we can do edgy too (it'd be similar kind of fixes)
[02:14] <StevenK> dholbach: That's conjecture at this point.
[02:14] <dholbach> right - I just feel that we need more information before we can move on and make a decision
[02:14] <Hobbsee> i cant really see a use case for non LTS releases - they're not servers, with the long support
[02:14] <minghua> I feel we lack important information -- affected packages, their versions in three releases, so maybe better discussed on list?
[02:14] <StevenK> I concur with both Hobbsee and dholbach
[02:15] <dholbach> minghua: right
[02:15] <ScottK> I can tell you that with some adjustments in version requirements in debian/control that don't appear to affect anything, you can build the current Gutsy clamav package on Dapper.
[02:15] <Fujitsu> Isn't Feisty alright, minghua?
[02:15] <ScottK> FWIW, keescook said he couldn't make it today, but he liked the clamav-alt plan
[02:15] <ScottK> Fujitsu: Feisty is OK today, but how long will that last.
[02:15] <Hobbsee> and klamav-alt, etc, plan, presumably
[02:15] <minghua> Fujitsu: I have no idea, I haven't touched clamav at all :-)
[02:16] <Fujitsu> ScottK: Ah yes, true.
[02:16] <StevenK> I personally don't like the -alt plan.
[02:16] <dholbach> let's form the team, make a wiki page with affected packages and let's try to rebuild them in dapper and edgy chroots with the new clamav and see how they work
[02:16] <Fujitsu> Has upstream considered any method of stopping this sort of thing happening in future?
[02:16] <StevenK> Fujitsu: You tell funny jokes.
[02:17] <ScottK> Their method is upgrade to the latest, it's less than 1.0, so no API stability is promised
[02:17] <Hobbsee> i think that for this type of stuff, we *need* to make sure we're communicating about what major base libs we're updating, so that the rdepends are fixed.
[02:17] <ScottK> One thing that will help in the futue is the with the klamav in Feisty the function to get a new upstream source, download it, compile it, and install it works.  I tested it.
[02:17] <StevenK> I wouldn't call libclamav2 a major base lib, fwiw. :-P
[02:17] <StevenK> ScottK: To /usr or /usr/local?
[02:18] <Hobbsee> well, no, i meant "something with over 10 rdepends of different source packages" or something
[02:18] <ScottK> To /usr/local iirc
[02:18] <StevenK> Hobbsee: Why 10?
[02:18] <Hobbsee> StevenK: because it's an arbitary number.
[02:18] <StevenK> Hobbsee: Good answer.
[02:18] <Hobbsee> StevenK: and because 42 was too high.
[02:18] <StevenK> ScottK: Good, just so long it doesn't wipe out the packages files.
[02:18] <ScottK> So in the future, klamav users will be able to bootstrap themselves
[02:18] <ScottK> StevenK: It doesn't.
[02:19] <crimsun> in the interest of time, can we agree to investigate offband and report back via the list?
[02:19] <dholbach> ok, let's get more information about the magnitude of work that lies in front of us
[02:19] <ScottK> I tested that
[02:19] <Hobbsee> crimsun: +1
[02:19] <ScottK> OK
[02:19] <dholbach> I agree with crimsun
[02:19] <StevenK> I concur with crimsun
[02:19] <dholbach> ScottK: I'm happy to help you with the team and announce it
[02:19] <dholbach> ScottK: let's discuss together with pitti and keescook
[02:19] <ScottK> OK
[02:20] <dholbach> ok, let's move on
[02:20] <dholbach> thanks ScottK
[02:20] <dholbach> persia: U-U-S Queue Procedure Review / Approval
[02:20] <persia> I've put together a draft guide for the workflow (and criteria) for managing the Ubuntu Universe Sponsors queue at https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue.
[02:20] <persia> The idea is to have a standard workflow that keeps us from stepping on each others toes and helps move towards an empty queue.
[02:20] <persia> I'd like to ask that people review it, and if there are no objections, that all people working on the queue follow this procedure.
[02:20] <ajmitch> & keeping it empty :)
[02:20] <joejaxx> :)
[02:20] <persia> ajmitch: Exactly
[02:20] <StevenK> I daresay u-u-s will never be empty. :-)
[02:21] <ajmitch> we can try
[02:21] <StevenK> Indeed.
[02:22] <geser> what about debdiffs or sync request that need some work from the submitter? should they be set to "needs info"?
[02:23] <dholbach> "in progress" and assign to the submitter?
[02:23] <Hobbsee> StevenK: it will when LP fixes a bug that i reported
[02:23] <persia> geser: Right, set to "Needs Info", unsub UUS, assign the submitter, and ask for resubscription when complete.
[02:23] <StevenK> I like dholbach's suggestion better.
[02:23] <StevenK> Hobbsee: ... that removes the team? :-P
[02:23] <Fujitsu> Hobbsee: The searching for bugs in some context subscribed to by someone?
[02:23] <Hobbsee> StevenK: no - lets us search by only ubuntu bugs subscribed by u-u-s
[02:24] <dholbach> can we make sure it is mentioned on  https://wiki.ubuntu.com/SponsorshipProcess ?
[02:24] <persia> dholbach: I prefer "Needs Info" for that.  "In Progress" implies someone is doing something.  I would expect the submitter to reset if they start work.
[02:24] <Hobbsee> geser: needs info, i'd prefer
[02:24] <dholbach> both is fine with me
[02:24] <StevenK> Yeah, okay, persia convinced me. "Needs Info" here too
[02:24] <geser> is that unsub U-U-S needed immediately?
[02:24] <persia> dholbach: I can add it to that page, but shouldn't we get acceptance by U-M-S first?
[02:25] <dholbach> persia: at least in the universe section of it
[02:25] <StevenK> I'm a member of u-m-s, but I can't speak for them.
[02:25] <persia> geser: I'd argue that unsub first is important: it reduces our bugmail.
[02:25] <dholbach> and yeah, good to get it discussed on devel-discuss too
[02:25] <Hobbsee> who's the head of it?  ajmitch?
[02:25] <persia> dholbach: OK.  I'll do that.
[02:25] <dholbach> excellent
[02:25] <StevenK> I thought pitti was.
[02:25] <Hobbsee> right
[02:25] <StevenK> Yes, it's pitti.
[02:25] <crimsun> point #5 under "Notes for Contributors" - can we clarify the distinction between "bugs that require approval by ubuntu-dev" and "bugs that represent a new candidate revision"?
[02:26] <ajmitch> Hobbsee: hm?
[02:26] <StevenK> Hrm. We could just drag pitti in here...
[02:26] <Hobbsee> ajmitch: sorry
[02:26] <Hobbsee> StevenK: not a bad idea
[02:26] <dholbach> and maybe refer to FreezeExceptionProcess too
[02:26] <pitti> hi
[02:26] <persia> crimsun: I was thinking rather to flesh out the MOTU/Contributing namespace (or MOTU Recipies), but we'll discuss that later.  If nothing happens, then yes.
[02:26] <crimsun> persia: ok.
[02:27] <persia> pitti I've put together a draft guide for the workflow (and criteria) for managing the Ubuntu Universe Sponsors queue at https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue.  What do you think about it for main?
[02:27] <geser> persia: no danger to lose some bugs as the submitter forgot to sub u-u-s again?
[02:27] <Hobbsee> i'm hesitant to use assignments with all of this - until someone's actually uploading the debdiff
[02:27] <pitti> oh, quite much, reading
[02:28] <StevenK> Surely we don't need to assign to ourselves when we upload?
[02:28] <Hobbsee> geser: then the subscriber really needs to learn to follow proceedures, as the buglist is too big to search randomly
[02:28] <Hobbsee> StevenK: cant really see where we need to assign ourselves at all, really
[02:28] <persia> geser: I don't think so.  I think with the new mentoring, we're developing enough active contributors that people will start searching for bugs with patches, and needs info that haven't been updated recently are good targets.
[02:28] <StevenK> Hobbsee: Agreed.
[02:28] <Hobbsee> oh, which is what is said.
[02:28] <persia> Hobbsee: Assignment is to make sure we don't collide.
[02:28] <dholbach> and we should have regular universe hug days
[02:29] <StevenK> persia: Surely we just comment saying "Mine! Hand's off"
[02:29] <Hobbsee> dholbach: regular revu days too - pick a day of the week for each
[02:29] <StevenK> Then again, that takes about as long as assigning it to yourself.
[02:29] <Hobbsee> StevenK: as long as someone comments on it asap, if they can see other people working on the buglist.  not half an hour later.
[02:29] <dholbach> Hobbsee: ok, let's get back to that on the 'regular' agenda point :)
[02:30] <Hobbsee> dholbach: ah, it's on the agenda already is it?  great.
[02:30] <persia> StevenK: I prefer assignment & in-progress, as it tells both the reporter and the submitter that someone is working on it in a nice way, and will translate better if LP ever gets localised bugmail.
[02:30] <StevenK> Hobbsee: Yeah, but the thought I had was it takes the same amount of time to do either.
[02:30] <persia> StevenK: Right.
[02:30] <Hobbsee> i dont care what people od, as long as they make it obvious
[02:30] <Hobbsee> else i will use the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!!!  on them.
[02:30] <StevenK> persia: Damn it, stop changing my mind for me!
[02:30] <pitti> persia: why 'fix committed' for uploaded packages with applied patches? that should be 'fix released'
[02:31] <persia> I want everyone to do the same thing.  That reduces confusion.
[02:31] <minghua> "fix released" only when it's built, I suppose?
[02:31] <Hobbsee> pitti: they all like doing that because they dont know if will build on all arches
[02:31] <gpocentek> hello guys, sorry for being late
[02:31] <Hobbsee> seems crazy to me
[02:31] <Hobbsee> hi gpocentek
[02:31] <persia> pitti: No.  The submitter should set to "Fix Released" if everything builds ok.  otherwise we haven't really realeased it.
[02:31] <Hobbsee> seeing as you will get emails of the buildlogs if it fails, and often people dont go back and do it.
[02:31] <pitti> Hobbsee: I disagree, uploaders will get mails about FTBFS, and bugs are just forgotten to be closed IMHO
[02:32] <persia> Hobbsee: We dont, only the submitter does.  This way, we can see the Fix Committed bugs in the +assigned list and clean up after them if required.
[02:32] <Hobbsee> pitti: that's either what i said, or what i meant to say.
[02:32] <pitti> persia: that's not really common practice, but *shrug* I can certainly live with it if the process makes sure that someone closes those bugs
[02:32] <persia> pitti: The person uploading doesn't get the mail: the last person in the changelog gets the mail.
[02:32] <Hobbsee> persia: you can also see the links in +packages
[02:32] <pitti> Hobbsee: yeah, I was just too slow with typing :)
[02:33] <Hobbsee> for the person who's name was in the changelog
[02:33] <persia> Hobbsee: When I sponsor, it doesn't appear in my +packages.
[02:33] <Hobbsee> which shows FTBFS, bugs, etc.
[02:33] <dholbach> how about we discuss this on the list too? I think it's better use of our time if we collect arguments about specific points there and propose it for main on ubuntu-devel-discuss@ a week later after we're all happy - in general it's a good proposal
[02:33] <Hobbsee> persia: no - it appears in the sponsoree's.
[02:33] <pitti> persia: then we should rather fix that to email both (Changed-By: person and sponsor)
[02:33] <Hobbsee> persia: who is the one responsible for it, of coruse.
[02:33] <persia> pitti: Maybe.
[02:33] <StevenK> pitti: I like that.
[02:34] <persia> dholbach: OK.  I'll send the mail inviting discussion.
[02:34] <Hobbsee> pitti: that'd be good
[02:34] <dholbach> persia: thanks a lot
[02:34] <pitti> persia: otherwise this sounds good to me
[02:34] <dholbach> persia: everything clarified?
[02:34] <persia> Let's move on, but if anyone wants to use the draft process in the meantime, that would be great.
[02:34] <dholbach> joejaxx: MOTU Reports/Statistics
[02:34] <joejaxx> alright
[02:34] <joejaxx> i have been generating statics on the archive for a release now
[02:34] <joejaxx> and some people have expressed that they would like expanded stats
[02:35] <Hobbsee> is this MOM type statistics, or waht?
[02:35] <joejaxx> right now i only do top uploaders and top 10 changed packages
[02:35] <joejaxx> top 10 uploaders*
[02:35] <geser> Hobbsee: http://ubuntu.joejaxx.org/
[02:36] <joejaxx> so i was wondering if there were any other statistics that people would like to have generated
[02:36] <ajmitch> top bugs opened/closed per week?
[02:36] <Hobbsee> numbers of unmet deps, numbers of broken (uninstallable) packages
[02:36] <dholbach> joejaxx: how about this: you put the source for the statistics generation in LP, create a product for it and ask people to file wishlist bugs on it?
[02:36] <Hobbsee> highest number of dupes bugs
[02:36] <joejaxx> dholbach: ok that sounds like a good idea
[02:36] <dholbach> that way you even get people who work with you on enhancing it
[02:36] <dholbach> excellent
[02:37] <dholbach> joejaxx: you had some other points on the agenda too
[02:37] <joejaxx> that way we have documented requets
[02:37] <Fujitsu> Or put it in LP. That'd make more sense, except...
[02:37] <Hobbsee> maybe even http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html type thing for universe if that helps
[02:37] <joejaxx> dholbach: ah yes
[02:37] <ajmitch> by the bug opened/closed, I mean like http://bugzilla.gnome.org/reports/weekly-bug-summary.cgi
[02:37] <StevenK> Hobbsee: Oooh, ouch, britney for universe.
[02:38] <StevenK> Hobbsee: Britney, much like her namesake is a pig.
[02:38] <joejaxx> i was wondering if anyone else thinks it would be a good idea to have lin{tian, da} reports on packages?
[02:38] <Hobbsee> StevenK: i think it may be a horrible output, though
[02:38] <dholbach> joejaxx: it'd be nice if you would announce it on the list, so you get maximum exposure and maximum input
[02:38] <joejaxx> dholbach: sure
[02:38] <dholbach> joejaxx: your next point was?
[02:38] <Hobbsee> this should be checked with teh developer weather report, from UDS, too.
[02:38] <StevenK> joejaxx: And then generation time goes up by exponentionally.
[02:38] <Hobbsee> a lot of this either is, or will be, generated for main
[02:38] <joejaxx> i am wondering how we would go about doing that
[02:39] <joejaxx> dholbach: lintian/linda reports
[02:39] <dholbach> right
[02:39] <StevenK> Weather Report, heh. "Gutsy is currently raining bugs."
[02:39] <Hobbsee> haha
[02:39] <dholbach> I think it's best adressed in a soyuz wishlist bug, what do you think?
[02:39] <joejaxx> dholbach: i am guessing that would have to be a discussion with the LP devel team?
[02:39] <dholbach> exactly
[02:39] <geser> ajmitch: something like http://people.ubuntu-in.org/~carthik/bugstats/ ?
[02:39] <joejaxx> dholbach: sure but i am wondering if anyone else sees the benefits from having them
[02:39] <dholbach> https://bugs.launchpad.net/soyuz
[02:39] <Hobbsee> are we looking to do package stats or bugstats here?
[02:40] <ajmitch> geser: except by package
[02:40] <ajmitch> Hobbsee: I was suggesting a mix
[02:40] <Hobbsee> i'd like to see package stats.  bugstats seem to already being done
[02:40] <Hobbsee> right
[02:40] <Hobbsee> at least somewhat
[02:40] <ajmitch> but I don't know how useful it'll really be
[02:40] <dholbach> what 'next steps' can we agree on here?
[02:40] <StevenK> Tell us who to beat for breaking a package?
[02:41] <Hobbsee> StevenK: no, just which packages are broken.
[02:41] <Fujitsu> StevenK: It's all my fault.
[02:41] <StevenK> Fujitsu: We know, thanks.
[02:41] <StevenK> Hobbsee: And therefore, who to blame. :-P
[02:41] <Hobbsee> yep
[02:42] <dholbach> ok... joejaxx: anything you want to discuss some more?
[02:42] <joejaxx> dholbach: well i am going to submit a wishlist bug for this and then poke the LP devs
[02:42] <dholbach> excellent
[02:42] <joejaxx> dholbach: nope i think everything was covered :)
[02:42] <Hobbsee> joejaxx: anything you can do yourself will be quicker
[02:42] <dholbach> laserjock is not here, he wanted clarification of the +mentoring functionatlity
[02:42] <Hobbsee> LP stuff takes at least 6 months, iirv
[02:42] <Fujitsu> Am I the only one who thinks that such a wishlist bug isn't going to get looked at for at least a couple of years?
[02:42] <Hobbsee> s/v/c/
[02:43] <dholbach> I don't think there's much to say about it, other than: use it, make heavy use of it
[02:43] <joejaxx> Hobbsee: oh ok
[02:43] <persia> That was raised in part because I asked that people listed on the old mentoring page +mentor some bugs.  What do people think?
[02:43] <dholbach> persia: I'm not sure I understand
[02:43] <crimsun> dholbach: would tie in nicely with a Q&A session (next agendum item)
[02:44] <persia> dholbach: Sorry.  Context.  LaserJock's agenda item.
[02:44] <dholbach> Fujitsu: if we can demonstrate the use it is for us
[02:44] <minghua> Fujitsu: well, I know important bugs in main packages that haven't been looked for years, so no surprise :-/
[02:44] <StevenK> An explanation of the mentoring system for idiots like me would be nice.
[02:44] <dholbach> ok
[02:44] <Hobbsee> StevenK: +1
[02:44] <Hobbsee> StevenK: to the explanation, -1 to the idiot part.
[02:44] <Fujitsu> dholbach: ... then it will get the motu tag added, and still sit around for at least a year or two.
[02:44] <StevenK> Hobbsee: :-)
[02:44] <Fujitsu> What Hobbsee said.
[02:44] <StevenK> Fujitsu: The first, or the second? :_P
[02:45] <crimsun> http://www.understated.co.uk/blog/2007/mentoring-in-launchpad/
[02:45] <Fujitsu> Both, of course.
[02:45] <dholbach> If you come across bugs that you would like to see fixed and that you are capable to fix, it's great to let somebody else the work and you share your knowledge and help develop new MOTUs
[02:45] <crimsun> is a great intro.
[02:45] <minghua> most bugs I'd like to mentor are in main packages :-(
[02:45] <dholbach> minghua: that's fine
[02:45] <persia> minghua: No reason you can't
[02:46] <minghua> and I can't find a team to label, so I didn't offer mentoring
[02:46] <dholbach> minghua: as long as you can help with them getting fixed - you can even explain the sponsoring process with that
[02:46] <minghua> LP needs to be fixed on that
[02:46] <dholbach> minghua: use ubuntu-dev for that as people who want to join ubuntu-dev will look there
[02:46] <persia> minghua: Use ubuntu-dev
[02:46] <minghua> okay, will do that, thanks
[02:46] <dholbach> Fujitsu: the LP people are very busy as everybody else - the best you can do is elaborate on why it's important for you
[02:47] <dholbach> any more questions about mentoring?
[02:47] <Hobbsee> yes
[02:47] <Hobbsee> how much is mentoring expected to be a spoon feeding process?
[02:48] <Fujitsu> Hobbsee: I suspect it will be a fair bit with -dev.
[02:48] <dholbach> pointing in the right direction and agreeing to review and correcting the mentoree should be it
[02:48] <Hobbsee> well, how much are we wanting it to be
[02:48] <persia> My experience is that the first bug is spoon feeding, but after that it works more smoothly.
[02:48] <persia> (for ech contributor)
[02:48] <Hobbsee> because i've go tthe feeling we're giving off the impression of "i need a mentor to do anything, and cant do anything until i get one"
[02:48] <dholbach> maybe the MOTU/Recipes will help with that
[02:49] <Hobbsee> and "they will be able to help me thru absolutely everything, all the time"
[02:49] <dholbach> Hobbsee: good point, I'll add that to the mentoring docs
[02:49] <Hobbsee> there doesnt seem tob e a "warning, you will need to actually think and put in work to do this" type idea.
[02:49] <StevenK> "Your mentor is not your guide to all things Ubuntu" etc, etc
[02:49] <Hobbsee> exactly
[02:49] <dholbach> it's not rude to ask people to try and check some manpages you list them
[02:49] <Hobbsee> "your mentor is not a substitute brain, nor substitute documentation"
[02:50] <dholbach> ok... any more questions?
[02:50] <Hobbsee> no - but i suspect people will view it as such regardless
[02:50] <StevenK> dholbach: Some people can take it as such,
[02:50] <dholbach> as long as you're being supportive and draw a line somewhere people will understand
[02:50] <Hobbsee> some extra special snowflakes then bitch about how the mentor wont do the work fro them, etc :P
[02:50] <crimsun> I'm happy to do a Q&A on mentoring if there's interest. (can even do ubuntu-audio bugs  *cough*)
[02:50] <Hobbsee> haha
[02:51] <Hobbsee> you really hate alsa, don't you, crimsun...
[02:51] <crimsun> no, I love it!
[02:51] <dholbach> ok, shall we move on? :)
[02:51] <Hobbsee> +1
[02:51] <dholbach> shall we have regular MOTU Q&A sessions, where contributors can ask questions and wiki-fy them afterwards?
[02:51] <dholbach> what about every two weeks?
[02:51] <Hobbsee> that sounds smart
[02:51] <StevenK> That isn't music you're hearing, it's the sound of computed gotos!
[02:52] <ajmitch> sounds good
[02:52] <dholbach> they don't need a special format, we just need to make sure some of us are there
[02:52] <Hobbsee> it seems to work better tahn the documentation - even people reading the logs of them afterwards
[02:52] <StevenK> dholbach: Sounds good to me too
[02:52] <ajmitch> dholbach: like the school? :)
[02:52] <StevenK> Heh
[02:52] <Hobbsee> i've often heard people going "i'm intending to go back and read teh MOTU school logs"
[02:52] <minghua> dholbach: are we trying to make an MOTU FAQ here?
[02:52] <StevenK> The School requires someone to be organise and teach. Q&A requires a bunch of people to answer questions.
[02:53] <Hobbsee> i suspect ti'd be slightly more in depth than that
[02:53] <Hobbsee> but ture
[02:53] <Hobbsee> this stuff should usually be added to the FAQ
[02:53] <crimsun> minghua: probably initially less "FA" and just more "Q" :)
[02:53] <StevenK> We have an FAQ?
[02:53] <dholbach> ok... first sessions May 31st? 0 UTC and 12 UTC?
[02:53] <minghua> I would like to see such sessions happen
[02:54] <Hobbsee> it's got hardly anything on it, but yes
[02:54] <crimsun> dholbach: sounds good.
[02:54] <geser> StevenK: the answer to this question can be found in the FAQ :)
[02:54] <dholbach> excellent
[02:54] <dholbach> I'll announce them
[02:54] <StevenK> geser: Oh, blah.
[02:54] <StevenK> :-p
[02:54] <minghua> we alternate 0 UTC and 12 UTC every other session, right?
[02:54] <crimsun> minghua: I think have both.
[02:54] <dholbach> minghua: I thought it'd be good to have 2 sessions
[02:54] <dholbach> so everybody has a chance to be there
[02:55] <minghua> oh, *and*, that's good
[02:55] <dholbach> (to have been in at least once)
[02:55] <dholbach> ok, moving on
[02:55] <dholbach> #
[02:55] <dholbach> DanielHolbach: start off ?MOTU/Recipes, where we walk people through
[02:55] <dholbach>    1.
[02:55] <dholbach>       making a small change and getting a debdiff for it
[02:55] <dholbach>    2.
[02:55] <dholbach>       updating a package
[02:55] <dholbach>    3.
[02:55] <dholbach>       dropping a dpatch in a package
[02:55] <dholbach>    4.
[02:55] <dholbach>       use pbuilder to test if Build-Depends are ok
[02:55] <dholbach>    5.
[02:55] <dholbach>       etc.
[02:55] <dholbach> this is something people have been constantly asking for
[02:55] <persia> To go with the sponsoring documentation, I've been drafting basic information to populate the MOTU/Contributing namespace.  This would include descriptions for Fixing Bugs (using MOTU/HowToPatch), Preparing Revisions (New Document), Packaging new software (new document), and pointers to MOTU/TODO for more things to do.  Would this meet the needs of MOTU/Recipies?
[02:55] <persia> My goal is something that looks like https://wiki.ubuntu.com/Bugs/HowToFix, but targeted at MOTU Contributors (with more knowledget, etc.).
[02:56] <dholbach> some repeatable steps that show them that it's not all rocket science and tools are easy to use and give them the feeling they achieved something
[02:56] <dholbach> persia: yes, that sounds very good
[02:57] <Hobbsee> +1 persia
[02:57] <dholbach> persia: maybe we should start each of those pages off with a series of steps they can just type in and see something happen that results in a debdiff or a package or something else
[02:57] <StevenK> persia: Sounds great.
[02:57] <dholbach> so they go from zero to hero in no time
[02:57] <dholbach> persia: what do you think?
[02:57] <persia> dholbach: Exactly.  I want to make something as easy to follow as HowToFix, but which generates more useful results (and takes a bit more work).
[02:57] <StevenK> dholbach: Oh wah, the cliches have to go. :-P
[02:58] <crimsun> (zero to hero!)
[02:58] <dholbach> StevenK: what do you mean?
[02:58] <dholbach> ok... who wants to help writing down those recipes?
[02:58] <dholbach> who else?
[02:59] <Hobbsee> persia: does
[02:59] <crimsun> I'll join
[02:59] <StevenK> I'll help proof-read, since I suck at writing from scratch.
[02:59] <persia> I'd actually prefer to draft everythnig myself to start (should be ready tomorrow or the next day), and encourages others to edit/polish, if that works.
[02:59] <dholbach> persia: that's fine too - can you mail ubuntu-motu@ about that?
[02:59] <Hobbsee> sounds sane
[02:59] <dholbach> persia: you ROCK! it's great to have you in the team!
[03:00] <dholbach> everybody hug persia :)
[03:00] <persia> Grrr..  With responsibility comes email.  I *liked* being a contributor.
[03:00] <crimsun> :-)
[03:00] <Hobbsee> haha
[03:00] <dholbach> :-)
[03:00] <Hobbsee> you can write filters for the email
[03:00] <persia> Hobbsee: That's work.  See above.
[03:00] <dholbach> any topic we forgot?
[03:00] <Hobbsee> hahaha
[03:00] <Hobbsee> point
[03:00] <dholbach> on the agenda?
[03:00] <Hobbsee> dholbach: world domination.
[03:00] <dholbach> Hobbsee: adressed by the other points, anything else?
[03:00] <crimsun> (I think that about covers the agendum)
[03:00] <Hobbsee> i believe we have impending universe iceape now, too
[03:01] <Hobbsee> which willb e fun, bug-wise
[03:01] <Fujitsu> Not more Mozilla :'(
[03:01] <StevenK> Oh, twitch.
[03:01] <dholbach> ok... when will we have our next Universe HUG Day?
[03:01] <StevenK> Debian has a trademark war, and we get sucked in too.
[03:01] <crimsun> May 31 0 UTC, 12 UTC.
[03:01] <dholbach> crimsun: so May 31st?
[03:01] <dholbach> I'd really like for us to make an effort to mark bugs as bitesize and offer mentoring
[03:02] <Hobbsee> the bitesize seems to work - just they all get done, and there's nothing left
[03:02] <dholbach> we need more tasks mentors can pass on to contributors, especially if it's an easy package update or something
[03:02] <crimsun> persia: this weekend, then?
[03:02] <StevenK> This weekend might be too short notice.
[03:02] <persia> crimsun: OK.  I like next better, as there'll be better docs on what people should do.
[03:02] <crimsun> next weekend?
[03:02] <dholbach> but that shouldn't hinder other to join in on the fun
[03:02] <crimsun> June 2?
[03:02] <Fujitsu> Yeah, 1 hour notice isn't very good.
[03:02] <dholbach> (next I'll be at linuxtag)
[03:03] <dholbach> but if the WE works best for everybody else, so be it :)
[03:03] <crimsun> if you don't mind, then, let's shoot for June 2
[03:03] <dholbach> alright
[03:03] <persia> dholbach: It's just that on the weekend, there are more people (not ubuntu-dev) with time to help.
[03:03] <dholbach> who write the announcement?
[03:03] <dholbach> persia: right
[03:04] <dholbach> ok, I'll write it
[03:04] <Hobbsee> who's doing the minutes and such?
[03:04] <dholbach> next motu meeting?
[03:04] <dholbach> in two weeks, same time? other time?
[03:04] <persia> June 15, 0 UTC?
[03:04] <dholbach> that'd be june 8th
[03:04] <StevenK> I can't make two weeks.
[03:05] <StevenK> Three, I can.
[03:05] <Hobbsee> this sort of time is good
[03:05] <StevenK> If it matters.
[03:05] <dholbach> that's 2 in the morning over here
[03:05] <crimsun> is 1300 UTC too much a burden on EU and AU?
[03:05] <persia> Hobbsee: To be fair to others, we need to adjust times :)
[03:05] <Hobbsee> i'll be in exam time by then, i guess - but i should be around some
[03:05] <StevenK> dholbach: A few hours earlier would work too.
[03:05] <dholbach> crimsun: not on EU
[03:05] <Hobbsee> persia: i'm well aware.  i'm australian, and i'm used to all the other meetings being at crap times.
[03:06] <Hobbsee> StevenK: what's 1300 local?
[03:06] <Fujitsu> 11pm
[03:06] <StevenK> 0200UTC
[03:06] <Hobbsee> oh, 11pm.  sounds sane
[03:06] <StevenK> Oh woops, wrong way
[03:06] <Hobbsee> sorry, 1300 UTC in local.  was unclear
[03:06] <Fujitsu> StevenK: We're +10 these days.
[03:06] <StevenK> Fujitsu: Hobbsee confused me.
[03:06] <StevenK> Which isn't hard at 11pm.
[03:06] <Hobbsee> poor StevenK
[03:06] <dholbach> ok... what do we agree on?
[03:07] <crimsun> June 15th 1300 UTC?
[03:07] <dholbach> wfm
[03:07] <StevenK> June 15th, 1300UTC sounds great to me.
[03:07] <Hobbsee> sounds sane, pending exams and such
[03:07] <dholbach> who writes the announce?
[03:07] <dholbach> excellent, thanks Hobbsee
[03:07] <Hobbsee> mind you, i said that about kubuntu-devel, and havent yet.
[03:07] <Hobbsee> i suck.
[03:07] <persia> I think it's unfair to people in NZ, and NA, but am happy myself.
[03:07] <crimsun> https://wiki.ubuntu.com/MOTUMenuHeader updated
[03:08] <ajmitch> persia: that's ok
[03:08] <dholbach> rock and roll
[03:08] <Hobbsee> does that mean i'm doing teh meeting minutes as well?
[03:08] <ajmitch> I won't be there
[03:08] <dholbach> thanks everybody - this was an awesome meeting
[03:08] <dholbach> lots of stuff covered
[03:08] <Hobbsee> it was!
[03:08] <Hobbsee> better than the UDS one, even
[03:08] <persia> There was a UDS MOTU meeting?
[03:08] <dholbach> Hobbsee: will you CC fridge-devel@?
[03:08] <Hobbsee> dholbach: yep
[03:08] <Hobbsee> persia: yeah, on reviewing
[03:08] <dholbach> alright
[03:09] <Hobbsee> and such
[03:09] <Hobbsee> and mentoring
[03:09] <StevenK> persia: In person at UDS.
[03:09] <persia> Ah, I remember now.  No links.
[03:09] <Hobbsee> there was VOIP
[03:09] <Hobbsee> the redneck was on it, iirc
[03:09] <persia> And gobby (until it broke)
[03:09] <Hobbsee> yeah, true
[03:10] <persia> Hobbsee: With full gain for extra breathing sounds :)
[03:10] <joejaxx> lol
[03:10] <Hobbsee> hehe
[03:11] <crimsun> thanks everyone!
[09:29] <nixternal> @schedule chicago