20070629
== Log === TZ UTC+1
01:00 dholbach to get some rotation going on, who would like to run today's meeting?
01:00 dholbach agenda is here: https://wiki.ubuntu.com/MOTU/Meetings
01:00 lionel hi
01:00 dholbach to get some rotation going on, who would like to write up the minutes of today's meeting?
=== persia volunteers to chair, if nobody else wants it
01:01 ScottK StevenK: Yes. You can quit wondering.
=== TheMuso would do the minutes, but he is going away for a week tomorrow.
=== persia retracts volunteering after reviewing the agenda
01:01 StevenK ScottK: :-P
01:01 TheMuso SO I can't be sure of getting them out before I go
01:02 dholbach ok, I'll run the meeting - if somebody could just take a very few notes, that'd be nice
01:02 dholbach persia's item is the first on the agenda: Should setting a date for REVU days be a Fixed topic?
01:02 dholbach I personally think that's a great idea
01:02 persia In the last couple MOTU meetings, there have been discussions of REVU days. Should this be a standard part of the Fixed Topics? That wold save anyone remembering each time.
=== ScottK too. Lets do it. Next item... ;-)
01:03 dholbach excellent idea
01:03 dholbach rock on - thanks persia - somebody please add it
01:03 StevenK Maybe not setting a date, but at least discussing it.
01:03 TheMuso +1
01:03 persia StevenK: I'd rather set a date each time.
01:03 persia (or attempt to do so)
01:03 dholbach yes, I think it's good to settle on it and get moving quickly
01:03 ScottK StevenK: Maybe we set a date like two months from today....
01:04 StevenK Fair enough.
01:04 Hobbsee persia: good idea
01:04 dholbach ok cool, moving on
01:04 dholbach persia's second item is: Does the Sponsorship Process need adjustment for SRUs?
01:04 dholbach hi crimsun
01:04 dholbach persia: what is the problem that you're seeing with sponsoring and SRUs?
01:04 persia The sponsorship queue seems to be working very well for bugs against gutsy, but SRUs are not being processed as quickly. Should there be a different procedure for these?
01:05 persia dholbach: Right. The SRUs aren't attracting as much sponsorship attention, and I'm wondering if a process change or a team would help.
=== Hobbsee doesnt do SRU's.
01:06 ScottK persia: My generic problem with the UUS queue is I have a hard time telling if something's ready to be sponsored if I only have time to deal with one or two.
01:06 ScottK So I look and throw up my hands.
01:06 ScottK And move on.
01:06 ScottK This is true for SRU or not.
01:06 dholbach so if I want to do a SRU, I file a bug, subscribe ubuntu-universe-sponsors to it and nobody will upload because it's feisty-proposed instead of gutsy in the upload target?
01:06 StevenK I think the problem is that sponsors might go, "Ooh, an SRU. I'm not qualified/care enough to deal with it, since SRUs are Big and Scary"
01:06 persia ScottK: My method is to grab the first couple and take a quick look. If something is funny, I invalidate and otherwise upload.
01:06 ScottK I did an SRU this week because it was one I hit that was ready.
01:07 TheMuso c
01:07 TheMuso ugh
01:07 persia dholbach: Some of them are being processed, but it doesn't happen as quickly.
=== persia seconds StevenK
01:08 crimsun what seems to be the mean lag order on SRU processing? Weeks? Months?
01:08 Hobbsee and you usually get shot down if the fix doesnt actually fix the problem, etc.
=== ScottK tends to think along the lines of it's really broken now (or it wouldn't qualify for SRU), so how much worse can I make it..
=== TheMuso hasn't done SRUs simply because he hasn't aquainted himself properly with the procedure, which is just a amtter of reading.
01:08 dholbach what could we do to request more reassurement?
01:08 persia crimsun: I haven't calculated that, but there are at least a couple that are from May.
01:08 StevenK Maybe an SRU should adopt a REVU like solution. Two ACKs for it to be okay, and the second one uploads it.
01:09 dholbach StevenK: that'd revert some parts of the universe sru process - we'd have a team that'd evaluate it again - I personally don't think that's wrong at all
01:09 ScottK Maybe people needing sponsoring for an SRU should add a tag for SRU and release (like sru edgy)
01:09 StevenK dholbach: I don't see that as being a bad thing, speaking as a former member of motu-sru. :-)
01:09 persia I think it would be better to have the ACK be optional, rather than required, just to not interfere with the security processing.
01:10 ScottK Once someone's reviewed it they add a tag like motu.
01:10 StevenK SRU isn't security. And shouldn't be.
01:10 ScottK StevenK: +1
01:10 dholbach I think it'd help if people just verified it and asked in #ubuntu-motu or in the mailing list for a second opinion
01:10 StevenK Which is informally my suggestion anyway
=== ScottK would join a team looking at SRUs.
01:11 dholbach ok, so how would we go about codifying it?
01:11 crimsun maybe it's a simple lack of publicity
01:11 persia The value to formalisation is that the docs will point people to the right thing (if someone writes a doc), whereas informal may not become part of out collective knowledge.
01:11 StevenK ScottK: We played that game, and then stopped
=== ScottK knows
01:11 dholbach maybe just add a tag needs-sru-verification or something?
=== ScottK prefers the tag approach.
01:12 persia StevenK: Is there a reason there couldn't be a volunteer team that worked on them, despite the lack of a formal requirement for ACK?
01:12 crimsun I'm not convinced that throwing more overhead into it really helps; people seemed unhappy with collecting ACKs
=== ScottK would help on a team, but doesn't think it's the best way.
01:12 StevenK crimsun: Agreed
01:12 TheMuso crimsun: +1
01:12 dholbach it wouldn't be a necessity
01:12 dholbach just asking for another opinion
01:12 dholbach (in case you're unsure)
01:13 dholbach that tag would say "I'm happy with it, but please make sure and upload if you think it's ok too"
01:14 persia Alternately, with -proposed in place, should there be a strong gatekeeper? Is there any reason not to upload if it looks sane, and let the standard SRU process filter?
01:14 StevenK Whereas you don't have to set it and can just upload it if you think it's okay as well
01:14 crimsun does LP have an interface for say, a weekly cron executed from tiber (or elsewhere) that would search for tagged SRU bug reports and send an email to ubuntu-motu@ ?
01:14 ScottK One process clarification.... If I sponsor someone's SRU, am I responsible for writing the mail to the mailing list/setting tags/etc or are they?
01:14 persia ScottK: currently, you are (I prefer the sponsoree to be responsible).
01:15 ScottK persia: That's what I thought.
01:15 ScottK That might also be a barrier to getting SRUs uploaded.
01:15 dholbach https://bugs.launchpad.net/ubuntu/+bugs?field.tag=motu-sru-verification
01:15 dholbach or something
01:15 ScottK Maybe we should change that. After all the one that wrote the fix is most familiar/cares.
01:16 TheMuso After reading the procedure, SRUs are now clearer to me, and are easier than I thought.
01:16 dholbach I think it'd be ok for the sponsor to tell the fix author to write the mail or for them to agree on a procedure
01:16 dholbach so they can figure it out on their own
01:17 persia Is there a mechanism (other than IRC) for removing the uploads from -proposed if the author doesn't follow-up?
01:17 ScottK persia: Unless they are known to be broken, I don't see a harm in leaving them there.
01:17 crimsun persia: the normal "file a bug, subscribe ubuntu-archive"
01:17 dholbach bug reports with ubuntu-archive subscribed?
01:20 dholbach does anybody object adding a tag to ask for a second opinion and making the sponsor-mails-the-lists rule more lax and wiki-ing and announcing it?
01:20 persia So, unless there is more discussion, I'll update the sponsor queue processing guide to indicate that SRUs should be uploaded to -proposed if sane, that MOTUs are welcome to use the motu-sru-verification tag if they aren't sure, and that the author may be responsible for the notifications and follow-up if so agreed in advance.
01:20 siretart hi! (sorry for being late)
01:20 StevenK persia: +1
=== Hobbsee requests keybuk's presence here for the MoM/DaD discussion
01:20 dholbach persia: great
01:20 ScottK persia: +1
01:20 dholbach thanks a lot persia
01:20 TheMuso +1
01:20 geser +1
01:20 ScottK siretart: Thanks for volunteering to be in charge of the revised SRU process.
01:21 dholbach ScottK: wants to talk about clamav
01:21 ScottK ;-)
01:21 ScottK dholbach: Let Adri2000 go first.
01:21 StevenK Purge clamav from the archive.
01:21 siretart ScottK: huh? sorry?
01:21 dholbach ok, I'm happy with that
=== ScottK understands he/lutin have to run.
01:21 StevenK Let's move on.
01:21 ScottK siretart: Just kidding.
=== StevenK smirks.
01:21 dholbach Lutin, Adri2000: your stage
01:21 dholbach https://wiki.ubuntu.com/DaDandMoM
01:21 Adri2000 okay
01:21 bashelier may I go ?
01:22 Adri2000 I think bashelier has a quick intro
01:22 Adri2000 ho
01:22 Adri2000 go
01:22 bashelier Ubuntu is a free and open-source distribution, then it seems normal to develop an open-source tool to replace a proprietary one. This is the case for MoM and DaD, and moreover when both tool, one free and one non-free, we usually use the free one. But the fact to have two merge tools is quite confusing, especially that MoM is supported by Canonical and DaD is not.
01:22 bashelier But the fact is that DaD seems to be, at least for universe, very used, see comments in http://dad.dunnewind.net/universe.php for example. Then there are several possible issue to this problem, see the wiki page https://wiki.ubuntu.com/DaDandMoM for further informations.
01:23 Adri2000 after a discussion in -motu, we set up this wikipage in order to solve this issue
01:23 Hobbsee what are we attempting to acheieve out of this? a recommendation on which to use? a way to find out if and how DaD/MoM can integrate?
01:23 Hobbsee i'm finding this slightly unclear
01:24 StevenK "MoM isn't free, ours is and apparently better, so let's use it for everything." is what I can see.
01:24 Adri2000 Hobbsee: avoid confusion, especially for newcomers, about which one to use, why there are two merge systems
01:24 persia StevenK: See Proposal #3
01:25 bashelier 3. Add DaD's features to MoM, and keep MoM closed
01:25 dholbach I think it's better to send the proposal to ubuntu-devel@ and CC keybuk
01:25 dholbach as the scope of the proposal is not just universe
01:25 dholbach and motu
01:25 siretart my 2 : the killer feature of DaD are the comments. they might not be as necessary for main, but I think they help a lot in universe.
01:25 TheMuso agreed. Core devs have to feel comfortable with this as well.
01:25 Hobbsee dholbach: i can do that. i was speaking to sabdfl about this earlier anyway, and he asked to be CC'd
01:26 dholbach nice
01:26 Hobbsee whihc things of DaD do we want added to MoM?
01:26 ScottK But someone should e-mail keybuck first so he doesn't get blindsided.
01:26 Adri2000 dholbach: but I haven't seen any core-dev using DaD, so I'm not sure they are very well aware of the problem
=== persia likes comments
01:26 bashelier Hobbsee: comments
01:26 siretart since it is used a lot in universe, I think we can settle on DaD for universe
01:26 Hobbsee sorry, i meant apart from the comments
01:26 dholbach Adri2000: we all agree that there should be one solution and comments are good
01:26 Hobbsee is there anything *apart* from them?
=== ScottK thinks the fact that it runs more often is good.
=== ScottK also like that it'll do the maintainer mangling for you.
01:26 persia I thought MoM ran every 15 minutes now.
01:27 Adri2000 Hobbsee: open-source, automatic maintainer update
01:27 Hobbsee Adri2000: auto maintainer update?
=== ScottK also likes the open source part.
01:27 TheMuso I'm not so sure that auto maintainer update is the best thing in the world
01:27 Hobbsee oh, maintainer mangling
01:27 persia I don't like the implementation of the auto-maintainer-update - it sometimes breaks things.
01:27 siretart Hobbsee: having active and responsive maintainers
01:27 Hobbsee hi Keybuk
01:27 Adri2000 Hobbsee: yes, DaD automagically updates the maintainer field if it isn't yet an @ubuntu.com address
01:27 dholbach Keybuk: https://wiki.ubuntu.com/DaDandMoM is the proposal we're talking about
01:28 Adri2000 using the update-maintainer script from Lutin
01:28 Lutin persia: please mails me about that with examples, will have a look asap
01:28 Adri2000 hi Keybuk
01:28 Hobbsee Keybuk: the upshot of this is, MoM is missing the comments field and maintainer mangling. The attempt is to find which one to use and recommend to prospective developers, looking into doing merging.
01:28 Lutin heya Keybuk
01:28 persia Lutin - it's the same class of bugs we discussed before for which I said I'd hunt a patch. No worries.
01:29 Hobbsee Keybuk: do you have any thoughts on this?
01:29 Keybuk MoM also fulfils our obligations to Debian about returning patches, which DaD doesn't
01:29 Lutin persia: ok, cool
01:30 sistpoty|work Keybuk: but that's unrelated with displaying stuff for merges, right?
01:30 Keybuk no
01:31 siretart Keybuk: espc. in universe land the commenting feature of DaD have been very helpful. Is there any possibility to 'free mom' (or at least the relevant parts) so that we can send you patches which implement them?
01:31 Keybuk it's part of the same process and tool
01:31 Keybuk siretart: that is a question for sabdfl
01:31 sistpoty|work Keybuk: the same tool, I can see, but in what way the same process?
01:31 Adri2000 Keybuk: I didn't know returning patches was MoM's job, but could have I known since MoM is closed? :)
01:32 Keybuk Adri2000: that is not a useful comment
01:32 Adri2000 that was just to introduce proposal #1
01:33 Keybuk from what I can see
01:33 Keybuk DaD has many of the problems we fixed with MoM a long time ago
01:33 Keybuk (reliance on snapshot.dn, for example)
01:33 Keybuk but has a prettier web interface
01:33 Keybuk MoM is pretty reliable and rock-solid, but has a web interface written by someone who hates HTML (me)
01:34 ScottK So isn't there some way we can take the best of both and (ironically) merge them?
01:34 Adri2000 Keybuk: how does MoM get the base version when it's not available on snapshot.d.n?
01:34 persia Keybuk: Could others help with the interface?
01:34 bashelier that's proposal #4
01:34 bashelier Free only part(s) of MoM, such as the UI
01:34 Keybuk the UI isn't non-free
01:34 Keybuk it's exactly what you see there, an HTML page that's written out by some crappy python
01:35 Keybuk MoM could write out a list of packages available for merging, and useful information about them, (such as URLs, version numbers, etc.) to a machine-parseable file
01:35 Keybuk that the DaD UI could pick up and use for tracking
01:36 dholbach what do you think about taking this to ubuntu-devel@ and also including sabdfl in the discussions?
01:36 persia Let's call that proposal #5
01:37 dholbach at the moment, I don't see us coming to a conclusion in this meeting
01:37 bashelier Keybuk: DaD UI is generated from something like http://dad.dunnewind.net/tomerge-universe, then it would be simple yes
=== ScottK thinks it should all be opened up unless there is a strong reason not.
01:38 sistpoty|work what if MoM will be out again during the next merge cycle?
=== ScottK also agrees with dholbach that it's not going to get completely solved here.
01:38 Keybuk ScottK: Canonical would like to be able to pay its developers, and would like to be able to offer tools such as MoM as a paid service to other distros
01:38 Keybuk that is the fundamental rationale for why we've never released the code
01:38 ScottK Keybuk: I understand there's a balance here.
01:39 Keybuk sistpoty|work: it won't?
01:39 sistpoty|work good :)
01:39 Keybuk it was down due to hardware issues; which are unrelated to the software
01:39 sistpoty|work but not unrelated to the freeness :P
01:39 ScottK From a user of the service perspective though, the why is irrelevant.
01:39 Keybuk totally unrelated
01:40 Keybuk if the source were open, you'd still need someone with good bandwidth and .5TB of risk
01:40 Keybuk uh, of disk
01:40 Keybuk :p
01:40 TheMuso hahaha
01:40 siretart bashelier: Adri2000: what do you think about MoM giving status about available packages to merge, and make DaD a frontend to that?
01:40 ScottK Yes. Getting that didn't seem to be a problem.
01:40 bashelier siretart: I also have a proposal #6
01:41 bashelier siretart: why not to keep both DaD and MoM, and join the comments, I mean have unique comments for the two tools, which would help to avoid duplicated work, and let the choice for the favorite tool.
01:41 bashelier but use DaD as an UI, why not.
01:41 Adri2000 siretart: I think it's a good idea
01:41 dholbach ok great
01:41 dholbach let's see how that works out
01:41 ScottK It's certainly a start.
01:41 Keybuk I have no problem with somebody implementing a UI for MoM (I can hardly call the current report html a UI :p)
01:41 Keybuk I can ensure that the appropriate data is available
01:41 dholbach nice :-)
01:41 Adri2000 Keybuk: and put this UI on merges.ubuntu.com?
01:42 AndyP like launchpad is closed but still accepts bug reports from it's users (good thing), is MoM open to bug reports/feature requests too?
01:42 Keybuk We also have no problem if a community member wishes access to the MoM source under an NDA, and can hack on it themselves
01:42 Keybuk AndyP: of course
01:42 Keybuk Adri2000: depending on what it's written in, sure
01:42 TheMuso I would like to see if any core devs have an opinion, as the new UI could effect them as well.
01:42 geser is MoM all python?
01:43 Keybuk geser: yes;
01:43 Lutin TheMuso: indeed
01:43 TheMuso Or at the least, get some core dev's thoughts.
01:43 Keybuk the usual theory with core-dev is that MoM implements the minimum necessary
01:43 TheMuso Right.
01:43 Keybuk we don't tend to care so much about claims, or treading on people's toes
01:43 Keybuk since we're a smaller team with a much smaller based of packages
01:44 dholbach ok, are there any more open questions about this item?
01:44 TheMuso Nevertheless, if the UI is going to change, wider opinions should be considered.
01:44 persia I'd like to see comments on main, if only to say (as a MOTU) - I'll be a while on this one - someone should grab it if they're interested.
01:45 Keybuk on the options on the wiki:
01:45 Keybuk #1 is probably untenable, unless you can persuade sabdfl of the benefits since it's his call
01:45 ScottK The DaD team working the UI should also consider the new/updated merges split that MoM has (and explain the difference somewhere).
01:45 Keybuk #2 is also untenable, since MoM does more than just "merges"; not to mention is a much more mature solution than DaD
01:45 Keybuk #3 seems reasonable from a UI POV.
01:45 Keybuk ScottK: hah
01:46 Keybuk ScottK: the DaD team could do a *much* better job <g>
01:46 Keybuk the difference between new/updated is "does the top entry in debian/changelog say 'gutsy'?"
01:46 ScottK Right.
01:46 Keybuk it assumes that if the package has ever been uploaded to the current distro, it is "updated"
=== ScottK only recently figured that out.
01:46 Keybuk so often updated things have never been merged
01:47 dholbach thanks a lot Lutin, bashelier and Adri2000 for working on this
01:48 dholbach is it ok to discuss the implications of the UI changes on the mailing list?
01:48 TheMuso +1
01:48 bashelier dholbach: yes
01:48 Adri2000 yep
01:48 Lutin yep
01:48 persia Sounds good to me.
01:48 dholbach thanks a lot - please write also to the mailing list once people can test the UI
01:49 siretart well, we need help from the MoM side
01:49 Lutin well, gotta run. see you later
01:49 dholbach bye Lutin - have a nice day
01:49 Keybuk siretart: scott AT ubuntu DOT com :-)
01:49 dholbach shall we move on to ScottK's item?
01:49 Keybuk (well, when I have my mail server running again <g>)
01:49 TheMuso Thanks for your time Keybuk.
01:49 dholbach thanks Keybuk
01:50 dholbach ScottK: https://lists.ubuntu.com/archives/ubuntu-motu/2007-June/001747.html - your stage
01:50 ScottK When last we met (that I was here) there was a move to go look at the API differences between libclamav1 and libclamav2 and see how big a deal they are. I asked for volunteers to work on that (I'm hopelessly unqualified) and got zero volunteers. The next idea I have for clamav and rdepends support is here: https://lists.ubuntu.com/archives/ubuntu-motu/2007-June/001747.html - I'll give everyone a minute to read ...
01:50 ScottK It's clear we need to do something, particularly for server LTS support.
01:50 Hobbsee thankyou Keybuk
01:50 ScottK Comments?
01:50 ajmitch as it is, clamav won't be getting updated definitions with 0.8x
01:51 persia I don't think a separate project works well, unless there is strong repository support. Also, it breaks things if volunteers don't step up for all the rdepends. Lastly, is makes security updates harder.
01:52 ScottK The trick is that by backporting just clamav, we can give the appearance of coverage, without the actuality. If you doubt me, go try and find a test virus with the version of clamtk released for Feisty.
01:52 ajmitch persia: that's ok, as it stands clamav can't get security fixes anyway :)
01:52 ScottK My thought is to have a team to test and then have a wiki to describe what's been tested/works/is broken so people know what they are getting into.
01:53 ajmitch ScottK: using PPAs?
01:53 persia ScottK: I like the idea of a team, but why not use normal SRUs for it all? It's a lot of things to push at once, but I'd rather see it in the normal archive.
01:53 ScottK ajmitch: I'm open on the exact mechanism. I'd envisioned repositories similar to -backports, but that would get the archive admins off the critical path.
01:54 dholbach I just checked - the diff between libclamav from dapper to gutsy is around 62K lines
01:54 ScottK persia: If there were enough resources to SRU everything that needed changing, we wouldn't be here.
01:54 ajmitch dholbach: that's just the library, right?
01:54 TheMuso ouch
01:54 persia ScottK: True.
01:54 ScottK clamav has a painful number of rdepends.
01:54 dholbach yes clamav*/libclamav
01:54 ScottK We won't get all of them.
01:55 ajmitch a lot of applications would need significant changes (new upstream versions) to work with the newer clamav
=== ScottK will do the stuff I use.
01:55 ScottK ajmitch: Yes. Definitely.
01:55 ScottK That's why the current clamav doesn't qualify for regular backports even.
01:55 dholbach up until now, it looks like added API (which is no trouble) and changed return values
01:56 dholbach it's not feasible to make a wiki page with lists of changes
01:56 TheMuso ~/c
01:56 TheMuso ugh
01:56 dholbach I think it'd take trial&error just trying to compile older versions with the newer clamav
01:56 ScottK dholbach: I was thinking more like a list of known to work/known not to work.
01:57 dholbach if we were to patch things
01:57 ScottK I think patching things just isn't going to get there as you couldn't backport the newer clamav until you had patches for ALL the rdepends.
01:57 ScottK Heat death of the Universe would happen first.
=== ajmitch imagines the pain if clamav was in main
01:57 dholbach we had 21 source package or something?
01:58 TheMuso ajmitch: I was thinking about that earlier.
01:58 dholbach ({build-,}depending on it?
01:58 geser yes, something like that
01:58 lionel do we know how they manage it in volatile.debian.net ? Here there are latest version of clamav. It may break things (I did not dig in it)
01:58 ajmitch TheMuso: at least then it'd be Not Our Problem :)
01:58 TheMuso ajmitch: heh
01:58 ScottK lionel: That's just the latest upstream.
01:58 ScottK It'll break things.
01:59 Hobbsee_ ajmitch: try not to think about it
01:59 lionel ah, thanks ScottK
01:59 dholbach ScottK: is dapper -> gutsy what we're looking at atm (regarding API breakage)?
01:59 ScottK No, Feisty.
01:59 ScottK Dapper -> Feisty.
01:59 dholbach ok
01:59 ScottK Feisty is good until the next API change...
01:59 dholbach what if we all grabbed a source package or two each and at least tried building it and see how it goes?
02:00 ScottK But as an example of the kinds of problems backporting the newer clamav's would cause, the clamtk in Feisty can't find virus.
02:00 TheMuso Could we try and encourage upstream to make it easier to support older versions with defs etc?
02:00 dholbach I won't pretend I hadn't other things to do, but I see it as the only realistic option atm
02:00 siretart ScottK: did you talk to upstream about the problem? how do they think about it?
02:00 dholbach for some build problems you could even find patches in the upstream cvs
02:00 ScottK siretart: Upgrade to the latest version.
02:00 dholbach most projects will have adapted to the new clam api
02:02 ajmitch trying to get those patches to apply to the older versions could be interesting
02:02 ScottK The basic clamav perspective, as I understand it, is there is no promise of API stability until they get to 1.0 and whatever happens in the mean time is a personal problem.
02:02 TheMuso hmpf
02:03 siretart ScottK: so they are not helpful at all. interesting
02:03 dholbach not pretty, but this might be a start for a clamtk patch: http://clamtk.cvs.sourceforge.net/clamtk/clamtk/clamtk?r1=1.45&r2=1.40&view=patch
=== ScottK thinks something needs to be done separate repo (or PPA) wise as otherwise everything needs to be upgraded in synch.
02:04 dholbach I still think that backporting clamav + fixing apps is not impossible
02:04 ScottK dholbach: But you need that for all the rdpends published at the same time you publish the new clamav
02:04 ScottK dholbach: It's the synchronization that'll be the problem.
02:05 dholbach you can add Breaks: for that
02:05 dholbach so people won't upgrade until the new version is in
=== persia likes the idea of 10 people each grabbing 2 packages, say Tuesday, and preparing a bundle.
02:05 dholbach it's ugly, but possible
02:05 ScottK Oh?
=== ScottK didn't know about that one.
02:05 dholbach assuming we had 'breaks:' in dapper already
02:06 ajmitch I don't think we did
02:06 dholbach adding conflicts for things like that is rather discouraged
02:06 persia Real Breaks: support is new for Gutsy, isn't it?
02:06 ScottK If you can do that, then it'd be doable.
02:06 ajmitch "The dpkg in edgy now supports a new kind of dependency relationship, `Breaks'"
02:06 ajmitch so, edgy
02:06 dholbach edgy, ok - hrm
02:06 ScottK So need to backport that first.
02:06 dholbach not going to happen
02:07 dholbach we won't upload a dpkg/apt with new features
02:07 ScottK Then that leaves the LTS release stil screwed.
02:07 dholbach we should discuss that point on the list
=== ScottK thinks that is a good idea for LTS +1
02:07 dholbach primarily we should try fixing the stuff
02:08 dholbach even if the deployment of the fix is still an open issue
02:08 ScottK dholbach: But without Breaks, we'd still need fixes for everything before we backport. That's never gonna happen.
02:08 dholbach ScottK: can you make a wiki page of the affected packages and ask for help in backporting them to work with the new clamav?
02:08 dholbach I'd sign up for one or two
02:09 ScottK First I guess we need to do testing.
02:09 dholbach I think we should offer a complete transition and attack the backport problem as a team
02:09 ScottK OK.
02:09 dholbach some might be easy, for some we might find upstream patches, some might be real work
02:09 dholbach but we'll never find out otherwise
=== ScottK can make a wiki page with a list of rdepends and people can mark it up as they test stuff.
02:09 dholbach great
02:10 dholbach trying to build them in a chroot is of real help already
02:10 ScottK One related point is that the unmodified source package for clamav won't build on Dapper.
02:10 ScottK It needs the Edgy dpgk.
02:10 sistpoty|work sorry, need to be off again... cya
02:10 dholbach see you sistpoty|work
02:10 dholbach ScottK: we should work around that
02:11 ScottK It's a two line change in debian/control.
02:11 dholbach that's fine
02:11 ScottK OK.
02:11 dholbach ok, shall we move on?
02:11 ScottK dholbach: So the action out of the meeting is for me to make a wiki page.
02:12 dholbach yes and announce it on the mailing list
02:12 TheMuso ~
02:12 TheMuso ~
02:12 TheMuso ugh
02:12 dholbach ScottK: thanks a lot for insisting on making a solution happen
02:12 ScottK dholbach: One sec
02:12 ScottK I also think we should make a team of interested people.
=== ScottK will do that too.
02:12 dholbach ok cool
02:12 ScottK OK, now move on...
02:12 dholbach thanks again ScottK
02:13 dholbach we have a few dates to agree on
02:13 dholbach next MOTU meeting?
02:13 dholbach 2 weeks from now? same time?
02:13 TheMuso Sounds good.
02:13 dholbach any objections?
02:13 Hobbsee that works
02:13 dholbach ok cool - who will announce it?
02:13 persia I'd like to see a time rotation, to be fair to those who haven't attended in a month. +/- 12 hours?
02:13 StevenK No objections, works for me.
02:13 Hobbsee my only objection is that two weeks aftre that, which will be the next proposed meeting, is likely during SLUG
02:14 Hobbsee which various members are planning to actually attend
02:14 StevenK The SLUG meeting is happening now, too
02:14 Hobbsee true
02:14 dholbach ok then thursday - move by 12h?
02:14 ScottK dholbach: Could we have it an hour or two later.
02:15 dholbach sure we can - we just need to agree
02:15 ajmitch dholbach: 12h earlier than now?
02:15 ScottK Make the next one +14 and then go +12 after that
02:15 dholbach ScottK: so time and date would be?
02:15 Hobbsee can you give absolute times please? not everyone lives on your timezone
02:15 dholbach (it'll be too late for me in europe, but that's fine)
02:15 ScottK OK, then maybe one hour.
02:16 ScottK 1200 UTC Friday, whicher date it is
02:16 ScottK Err
02:16 ScottK 0000 UTC Saturday
02:16 ScottK Then 1200 UTC after that
02:17 dholbach I won't be around - as I'll be in london at that time, but that's fine with me if others can agree on it
02:17 ScottK Anyone?
02:17 persia I like 0 UTC (as part of rotation).
02:18 ScottK 0/12000 UTC. Any objections?
02:18 TheMuso No.
02:18 Hobbsee should be OK here, 10am
02:18 dholbach so that'd be two meetings?
02:19 persia dholbach: No. 0 UTC is proposed for now + 2 weeks, with 12 UTC sugggested for now L 4 weeks (we'll review in 2 weeks).
02:19 dholbach ok fine with me
02:19 dholbach who announces it?
02:20 dholbach come on
=== persia volunteers for week-in-advance email, but would likely again forget the day-in-advance email.
02:20 dholbach persia: thanks
02:20 dholbach next Universe HUG DAY?
02:20 dholbach I'd like us to make an effort to tag bugs and offer mentoring for them
02:20 dholbach I get a lot of requests of people who don't know where to start helping out
02:21 dholbach we should make an effort to help newcomers into the team :)
02:21 dholbach so what about friday next week?
02:22 ajmitch sounds ok
02:22 TheMuso next week?
=== TheMuso won't be here.
02:22 dholbach who of you will help out?
=== ajmitch probably can, since it'll be saturday
=== ScottK will be around, but working so can help some.
02:22 ajmitch nothing better to do on a friday night :)
02:23 dholbach ok, if there's no other proposal, let's go with that, I'll announce it
02:23 dholbach next Q&A sessions?
02:23 dholbach was anybody of you there yesterday?
02:23 ajmitch nope
02:24 dholbach would it be ok to do them in #ubuntu-motu?
02:24 Hobbsee i'd suggest that's a good idea
=== TheMuso thinks so
02:24 dholbach ok
02:24 persia That seems a better place.
02:24 AndyP i think it was forgotten about, and no one turned up in #ubuntu-classroom looking for Q&A... perhaps better advertising next time :)
02:24 dholbach shall we do them in thursday two weeks at 0 and 12 utc?
02:24 dholbach if you have a blog, please blog about all the events we do
02:25 dholbach I'll do that too and announce the Q&A sessions, if we agree on the date and time
02:25 dholbach ok, I take that as no objections
02:25 dholbach moving on
02:25 dholbach next REVU day?
02:26 dholbach as the situation is rather desperate.... what about monday? :-)
=== persia wonders if there is a good definition of expected activities for a REVU day.
02:26 TheMuso I'd rather not have it in the next week, as I'd like to help, but won't be around.
02:26 dholbach TheMuso: we'll do another revu day the week after that - how about that?
02:26 dholbach so best to agree on two dates
02:26 TheMuso dholbach: I'm easy, but would like to help
02:27 dholbach persia: working through the lists of REVU and ubuntu-{main,universe}-sponsors?
02:27 persia So two days? I like Tuesdays or Thursdays.
02:27 dholbach TheMuso: cool
02:27 dholbach oh, I mean a day each in next week and the one after that
02:27 persia dholbach: Ah. I wonder if there shouldn't be a wiki page or something.
02:27 ScottK Wed next week is a major holiday in the US.
02:27 dholbach persia: MOTU/Reviewing? :)
02:28 dholbach ScottK: so you think it'd be a good thing to do it on wednesday?
02:28 ScottK dholbach: No. Stay away from it.
02:28 dholbach ok
02:28 dholbach the next two mondays then?
02:28 ScottK Independence Day generally has a lot of people outside and away from computers here.
02:29 persia dholbach: Cluttered namespace, but I'll add a note on REVU days to https://wiki.ubuntu.com/MOTU/Packages/Reviewing
02:29 ScottK Many people travel too, so Monday is good.
02:29 dholbach persia: thanks
02:29 dholbach ok cool
02:29 dholbach I'll make sure to announce it
02:29 dholbach and please blog about it, if you can - it's good to stir up some interest in the activities we do, they deserve it :)
=== TheMuso needs to get a blog first.
02:29 dholbach I think that's all from our agenda
02:30 TheMuso :p
02:30 dholbach do we have anything else?
02:30 jhansonxi I have a question about Wine desktop files
=== ScottK thinks congratulations are in order for our two new MOTUs.
02:30 dholbach jhansonxi: would it be ok to ask it in #ubuntu-motu?
02:30 dholbach ScottK: absolutely
02:30 ScottK just a note for the minutes
02:31 ScottK Since I don't think either is present.
02:31 ajmitch are we up to date with new MOTU applications?
02:31 dholbach thanks calc and nixternal for all the work you put into Ubuntu :-)
02:31 ScottK Actually, congrats nixternal
02:31 dholbach ajmitch: no, bluekuja and YokoZar and one core-dev application are in the loop
02:32 dholbach ok, that's that then
02:32 dholbach thanks all for coming - have a nice day
02:32 TheMuso np
=== ajmitch presumes that they can be approved with 3 or 4 out of 5 giving a response
02:33 dholbach ajmitch: bluekuja and yokozar don't have any vote
02:33 ajmitch ok
=== ajmitch should sleep now anyway
=== GNUdog_ is now known as GNUdog
=== persia wonders if welcome of new MOTUs and status of pending applications should be a regular item.
02:34 dholbach welcoming new MOTUs should be
02:34 dholbach I already sent mails to ubuntu-devel@ about it
02:34 dholbach but it'd be nice to welcome them in the meeting also
02:35 dholbach for status of pending applications I'm not sure
02:35 dholbach I mean I'm happy to give a statement on it, but I don't know if it helps much
02:35 persia Right. I withdraw that - it's properly MOTU Council.
02:35 ajmitch and we don't have separate MC meetings
02:36 persia ajmitch: But you deliberate in other forums, no?
02:36 ajmitch only the mailing list
02:37 persia Hmm. I stand by my withdrawl, but wouldn't oppose another suggesting it.
02:37 ajmitch ok, meeting over, let's all go home :)MeetingLogs/MOTU/20070629 (last edited 2008-08-06 16:27:01 by localhost)