=== blenderhead001 [n=blenderh@adsl-068-209-133-121.sip.jax.bellsouth.net] has joined #ubuntu-meeting === licio [n=licio@ubuntu/member/licio] has joined #ubuntu-meeting === Ju` is now known as Ju === doko_ [n=doko@dslb-088-073-091-187.pools.arcor-ip.net] has joined #ubuntu-meeting === doko__ [n=doko@dslb-088-073-096-158.pools.arcor-ip.net] has joined #ubuntu-meeting === hoora_ [i=ariel@gateway/tor/x-3917fcd00b4be3d4] has joined #ubuntu-meeting === neversfelde|mobi [n=neversfe@nrbg-4d071327.pool.mediaWays.net] has joined #ubuntu-meeting === licio_ [n=licio@c9500471.bhz.virtua.com.br] has joined #ubuntu-meeting === licio_ [n=licio@c9500471.bhz.virtua.com.br] has joined #ubuntu-meeting === mjg59 [n=mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting === karimfayez [n=karim@196.219.129.102] has joined #ubuntu-meeting === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-meeting === Admiral_Chicago_ [n=Freddy@adsl-76-223-80-221.dsl.chcgil.sbcglobal.net] has joined #ubuntu-meeting === Admiral_Chicago_ [n=Freddy@ubuntu/member/admiral-chicago] has left #ubuntu-meeting [] === merriam_ [n=merriam@85-211-239-240.dyn.gotadsl.co.uk] has joined #ubuntu-meeting === neversfelde|mobi [n=neversfe@nrbg-4d07149f.pool.mediaWays.net] has joined #ubuntu-meeting === zul_ [n=chuck@mail.edgewater.ca] has joined #ubuntu-meeting === licio [n=licio@ubuntu/member/licio] has joined #ubuntu-meeting === lfittl [n=lfittl@2001:6f8:107e:30:216:36ff:fe17:3cef] has joined #ubuntu-meeting === never|mobi [n=neversfe@nrbg-4d07149f.pool.mediaWays.net] has joined #ubuntu-meeting === Shely [n=huahua@60.20.49.26] has joined #ubuntu-meeting === cynics [n=cynics@123.116.101.251] has joined #ubuntu-meeting === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-meeting === Admiral_1hicago_ [n=Freddy@adsl-76-223-80-221.dsl.chcgil.sbcglobal.net] has joined #ubuntu-meeting === Admiral_Chicago_ [n=Freddy@ubuntu/member/admiral-chicago] has left #ubuntu-meeting [] === anibal [n=anibal@debian/developer/anibal] has joined #ubuntu-meeting === anibal [n=anibal@debian/developer/anibal] has left #ubuntu-meeting ["Leaving"] === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-meeting === asac_ [n=asac@debian/developer/asac] has joined #ubuntu-meeting === hjmf_ [n=hjmf@150.Red-83-44-175.dynamicIP.rima-tde.net] has joined #ubuntu-meeting === AndyP [n=andyp@ubuntu/member/welshbyte] has joined #ubuntu-meeting === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #ubuntu-meeting === oxxa [n=axxo@83.217.70.247] has joined #ubuntu-meeting === zakame [n=zakame@ubuntu/member/zakame] has joined #ubuntu-meeting === Fujitsu [n=fujitsu@ubuntu/member/fujitsu] has joined #ubuntu-meeting === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-meeting === oxxa_ [n=axxo@83.217.70.247] has joined #ubuntu-meeting === zul_ [n=chuck@mail.edgewater.ca] has joined #ubuntu-meeting === highvoltage [n=highvolt@196.1.61.44] has joined #ubuntu-meeting === bashelier [n=bashelie@srv122.hosteur.com] has joined #ubuntu-meeting === oxxa [n=axxo@gentoo/developer/axxo] has joined #ubuntu-meeting === pkl_ [n=phillip@unaffiliated/pkl/x-764568] has joined #ubuntu-meeting === gouki [n=gouki@ubuntu/member/gouki] has joined #ubuntu-meeting === [PUPPETS] Gonzo [i=gonzo@80.69.47.16] has joined #ubuntu-meeting === _[PUPPETS] Gonzo [i=gonzo@80.69.47.16] has joined #ubuntu-meeting === pkl__ [n=phillip@lougher.demon.co.uk] has joined #ubuntu-meeting === gouki_ [n=gouki@ubuntu/member/gouki] has joined #ubuntu-meeting === zul [n=chuck@mail.edgewater.ca] has joined #ubuntu-meeting === highvoltage [n=highvolt@196.1.61.44] has joined #ubuntu-meeting === bashelier [n=bashelie@srv122.hosteur.com] has joined #ubuntu-meeting === thekorn_ [n=thekorn@a89-182-133-18.net-htp.de] has joined #ubuntu-meeting === dholbach [n=daniel@i59F77EBF.versanet.de] has joined #ubuntu-meeting === juliux [n=juliux@ubuntu/member/juliux] has joined #ubuntu-meeting [08:43] @schedule sydney [08:43] Schedule for Australia/Sydney: 29 Jun 21:00: MOTU Team | 04 Jul 05:00: Technical Board | 05 Jul 06:00: Edubuntu | 06 Jul 06:00: Ubuntu Development Team | 11 Jul 01:00: Kernel Team | 11 Jul 22:00: Edubuntu === allee [n=ach@dialin-212-144-131-137.pools.arcor-ip.net] has joined #ubuntu-meeting === tkjacobsen [n=tkjacobs@h59ec0f85.c45-01-03.dyn.perspektivbredband.net] has joined #ubuntu-meeting === lionel [n=lionel@ip-211.net-81-220-127.rev.numericable.fr] has joined #ubuntu-meeting === slomo [n=slomo@ubuntu/member/slomo] has joined #ubuntu-meeting === emonkey-m [n=emonkey@static-pro-212-101-27-121.adsl.solnet.ch] has joined #ubuntu-meeting === asac_ [n=asac@debian/developer/asac] has joined #ubuntu-meeting === PriceChild [n=pricechi@ubuntu/member/pricechild] has joined #ubuntu-meeting === mc44 [n=mc44@unaffiliated/mc44] has joined #ubuntu-meeting [11:05] @schedule shanghai [11:05] Schedule for Asia/Shanghai: 29 Jun 19:00: MOTU Team | 04 Jul 03:00: Technical Board | 05 Jul 04:00: Edubuntu | 06 Jul 04:00: Ubuntu Development Team | 10 Jul 23:00: Kernel Team | 11 Jul 20:00: Edubuntu === neversfelde|mobi [n=neversfe@nrbg-4d07149f.pool.mediaWays.net] has joined #ubuntu-meeting === tkjacobsen [n=tkjacobs@h59ec0f85.c45-01-03.dyn.perspektivbredband.net] has joined #ubuntu-meeting === mvo [n=egon@p54A6725F.dip.t-dialin.net] has joined #ubuntu-meeting === geser [i=mb@ubuntu/member/geser] has joined #ubuntu-meeting === persia [n=persia@ubuntu/member/persia] has joined #ubuntu-meeting === persia [n=persia@ubuntu/member/persia] has joined #ubuntu-meeting === relix [n=david@d51A403D1.access.telenet.be] has joined #ubuntu-meeting === ranf [n=ralfm@dslb-084-058-096-068.pools.arcor-ip.net] has joined #ubuntu-meeting === sky_walki [i=czzhrd02@xdsl-563.lodz.dialog.net.pl] has joined #ubuntu-meeting === sky_walkie [i=czzhrd02@xdsl-563.lodz.dialog.net.pl] has joined #ubuntu-meeting === afflux [i=fnord@pentabarf.de] has joined #ubuntu-meeting === emonkey-m [n=emonkey@static-pro-212-101-27-121.adsl.solnet.ch] has joined #ubuntu-meeting === emonkey-m [n=emonkey@static-pro-212-101-27-121.adsl.solnet.ch] has joined #ubuntu-meeting === anibal [n=anibal@debian/developer/anibal] has joined #ubuntu-meeting === sky_walkie [i=czzhrd02@xdsl-563.lodz.dialog.net.pl] has left #ubuntu-meeting [] === lfittl [n=lfittl@2001:6f8:107e:30:216:36ff:fe17:3cef] has joined #ubuntu-meeting === anibal [n=anibal@debian/developer/anibal] has left #ubuntu-meeting ["Leaving"] [12:48] @schedule Paris [12:48] Schedule for Europe/Paris: 29 Jun 13:00: MOTU Team | 03 Jul 21:00: Technical Board | 04 Jul 22:00: Edubuntu | 05 Jul 22:00: Ubuntu Development Team | 10 Jul 17:00: Kernel Team | 11 Jul 14:00: Edubuntu === ..[topic/#ubuntu-meeting:ubotu] : Current meeting: MOTU Team | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 03 Jul 19:00 UTC: Technical Board | 04 Jul 20:00 UTC: Edubuntu | 05 Jul 20:00 UTC: Ubuntu Development Team | 10 Jul 15:00 UTC: Kernel Team | 11 Jul 12:00 UTC: Edubuntu === Lutin [n=Lutin@ubuntu/member/lutin] has joined #ubuntu-meeting [12:57] hey Lutin === Zic [n=Zic@Final-Fantasy.FF-IRC.net] has joined #ubuntu-meeting [12:57] @now [12:57] Current time in Etc/UTC: June 29 2007, 10:57:27 - Current meeting: MOTU Team [12:57] heya bashelier [12:57] o/ Lutin :) [12:57] hi Zic [12:59] hiya [12:59] Hi [12:59] hello [12:59] who else from the MOTU crew do we have here? === ajmitch is sort of here, if I count === persia is present [12:59] hi === TheMuso [n=luke@ubuntu/member/themuso] has joined #ubuntu-meeting [01:00] ScottK here === StevenK [n=stevenk@14.5.233.220.exetel.com.au] has joined #ubuntu-meeting === TheMuso is here. === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-meeting [01:00] Hrm. Wonder if ScottK is here this time. [01:00] to get some rotation going on, who would like to run today's meeting? [01:00] agenda is here: https://wiki.ubuntu.com/MOTU/Meetings [01:00] hi [01:00] 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 === pygi [n=mario@83-131-1-43.adsl.net.t-com.hr] has joined #ubuntu-meeting [01:01] 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] ScottK: :-P [01:01] SO I can't be sure of getting them out before I go [01:02] ok, I'll run the meeting - if somebody could just take a very few notes, that'd be nice [01:02] persia's item is the first on the agenda: Should setting a date for REVU days be a Fixed topic? === man-di [n=mkoch@dyndsl-080-228-194-004.ewe-ip-backbone.de] has joined #ubuntu-meeting [01:02] I personally think that's a great idea [01:02] 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] excellent idea [01:03] rock on - thanks persia - somebody please add it [01:03] Maybe not setting a date, but at least discussing it. [01:03] +1 [01:03] StevenK: I'd rather set a date each time. [01:03] (or attempt to do so) [01:03] yes, I think it's good to settle on it and get moving quickly [01:03] StevenK: Maybe we set a date like two months from today.... [01:04] Fair enough. [01:04] persia: good idea === crimsun [n=crimsun@pdpc/supporter/silver/crimsun] has joined #ubuntu-meeting [01:04] ok cool, moving on [01:04] persia's second item is: Does the Sponsorship Process need adjustment for SRUs? [01:04] hi crimsun [01:04] persia: what is the problem that you're seeing with sponsoring and SRUs? [01:04] 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] 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] 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] So I look and throw up my hands. [01:06] And move on. [01:06] This is true for SRU or not. [01:06] 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] 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] 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] I did an SRU this week because it was one I hit that was ready. [01:07] c [01:07] ugh [01:07] dholbach: Some of them are being processed, but it doesn't happen as quickly. === persia seconds StevenK [01:08] what seems to be the mean lag order on SRU processing? Weeks? Months? [01:08] 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] what could we do to request more reassurement? [01:08] crimsun: I haven't calculated that, but there are at least a couple that are from May. [01:08] Maybe an SRU should adopt a REVU like solution. Two ACKs for it to be okay, and the second one uploads it. [01:09] 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] Maybe people needing sponsoring for an SRU should add a tag for SRU and release (like sru edgy) [01:09] dholbach: I don't see that as being a bad thing, speaking as a former member of motu-sru. :-) === afflux [i=fnord@pentabarf.de] has left #ubuntu-meeting [] [01:09] 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] Once someone's reviewed it they add a tag like motu. [01:10] SRU isn't security. And shouldn't be. [01:10] StevenK: +1 [01:10] I think it'd help if people just verified it and asked in #ubuntu-motu or in the mailing list for a second opinion === jhansonxi [n=jhansonx@d24.as1.lnng1.mi.core.com] has joined #ubuntu-meeting [01:10] Which is informally my suggestion anyway === ScottK would join a team looking at SRUs. [01:11] ok, so how would we go about codifying it? [01:11] maybe it's a simple lack of publicity [01:11] 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] ScottK: We played that game, and then stopped === ScottK knows [01:11] maybe just add a tag needs-sru-verification or something? === ScottK prefers the tag approach. [01:12] 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] 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] crimsun: Agreed [01:12] crimsun: +1 [01:12] it wouldn't be a necessity [01:12] just asking for another opinion [01:12] (in case you're unsure) [01:13] that tag would say "I'm happy with it, but please make sure and upload if you think it's ok too" [01:14] 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] Whereas you don't have to set it and can just upload it if you think it's okay as well [01:14] 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] 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] ScottK: currently, you are (I prefer the sponsoree to be responsible). [01:15] persia: That's what I thought. [01:15] That might also be a barrier to getting SRUs uploaded. [01:15] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=motu-sru-verification [01:15] or something [01:15] Maybe we should change that. After all the one that wrote the fix is most familiar/cares. === sistpoty|work [n=potyra@faui31w.informatik.uni-erlangen.de] has joined #ubuntu-meeting [01:16] After reading the procedure, SRUs are now clearer to me, and are easier than I thought. [01:16] 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] so they can figure it out on their own [01:17] Is there a mechanism (other than IRC) for removing the uploads from -proposed if the author doesn't follow-up? [01:17] persia: Unless they are known to be broken, I don't see a harm in leaving them there. [01:17] persia: the normal "file a bug, subscribe ubuntu-archive" [01:17] bug reports with ubuntu-archive subscribed? [01:20] 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] 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] hi! (sorry for being late) [01:20] persia: +1 === Hobbsee requests keybuk's presence here for the MoM/DaD discussion [01:20] persia: great [01:20] persia: +1 === Pici [n=pcmacman@unaffiliated/pici] has joined #ubuntu-meeting [01:20] thanks a lot persia [01:20] +1 [01:20] +1 [01:20] siretart: Thanks for volunteering to be in charge of the revised SRU process. [01:21] ScottK: wants to talk about clamav [01:21] ;-) [01:21] dholbach: Let Adri2000 go first. [01:21] Purge clamav from the archive. [01:21] ScottK: huh? sorry? [01:21] ok, I'm happy with that === ScottK understands he/lutin have to run. [01:21] Let's move on. [01:21] siretart: Just kidding. === StevenK smirks. [01:21] Lutin, Adri2000: your stage [01:21] https://wiki.ubuntu.com/DaDandMoM [01:21] okay [01:21] may I go ? [01:22] I think bashelier has a quick intro [01:22] ho [01:22] go [01:22] 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] 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] after a discussion in -motu, we set up this wikipage in order to solve this issue [01:23] 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] i'm finding this slightly unclear [01:24] "MoM isn't free, ours is and apparently better, so let's use it for everything." is what I can see. [01:24] Hobbsee: avoid confusion, especially for newcomers, about which one to use, why there are two merge systems [01:24] StevenK: See Proposal #3 [01:25] 3. Add DaD's features to MoM, and keep MoM closed [01:25] I think it's better to send the proposal to ubuntu-devel@ and CC keybuk [01:25] as the scope of the proposal is not just universe [01:25] and motu [01:25] 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] agreed. Core devs have to feel comfortable with this as well. [01:25] dholbach: i can do that. i was speaking to sabdfl about this earlier anyway, and he asked to be CC'd [01:26] nice [01:26] whihc things of DaD do we want added to MoM? [01:26] But someone should e-mail keybuck first so he doesn't get blindsided. [01:26] 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] Hobbsee: comments [01:26] since it is used a lot in universe, I think we can settle on DaD for universe [01:26] sorry, i meant apart from the comments [01:26] Adri2000: we all agree that there should be one solution and comments are good [01:26] 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] I thought MoM ran every 15 minutes now. [01:27] Hobbsee: open-source, automatic maintainer update [01:27] Adri2000: auto maintainer update? === ScottK also likes the open source part. [01:27] I'm not so sure that auto maintainer update is the best thing in the world [01:27] oh, maintainer mangling [01:27] I don't like the implementation of the auto-maintainer-update - it sometimes breaks things. [01:27] Hobbsee: having active and responsive maintainers === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-meeting [01:27] hi Keybuk [01:27] Hobbsee: yes, DaD automagically updates the maintainer field if it isn't yet an @ubuntu.com address [01:27] Keybuk: https://wiki.ubuntu.com/DaDandMoM is the proposal we're talking about [01:28] using the update-maintainer script from Lutin === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-meeting [01:28] persia: please mails me about that with examples, will have a look asap [01:28] hi Keybuk === Nicke_ [n=niclasa@ua-83-227-140-135.cust.bredbandsbolaget.se] has joined #ubuntu-meeting [01:28] 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] heya Keybuk [01:28] Lutin - it's the same class of bugs we discussed before for which I said I'd hunt a patch. No worries. [01:29] Keybuk: do you have any thoughts on this? === tkjacobsen [n=tkjacobs@h59ec0f85.c45-01-03.dyn.perspektivbredband.net] has joined #ubuntu-meeting [01:29] MoM also fulfils our obligations to Debian about returning patches, which DaD doesn't [01:29] persia: ok, cool [01:30] Keybuk: but that's unrelated with displaying stuff for merges, right? [01:30] no [01:31] 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] it's part of the same process and tool [01:31] siretart: that is a question for sabdfl [01:31] Keybuk: the same tool, I can see, but in what way the same process? [01:31] Keybuk: I didn't know returning patches was MoM's job, but could have I known since MoM is closed? :) [01:32] Adri2000: that is not a useful comment [01:32] that was just to introduce proposal #1 [01:33] from what I can see === crimsun [n=crimsun@pdpc/supporter/silver/crimsun] has left #ubuntu-meeting [] [01:33] DaD has many of the problems we fixed with MoM a long time ago [01:33] (reliance on snapshot.dn, for example) [01:33] but has a prettier web interface [01:33] MoM is pretty reliable and rock-solid, but has a web interface written by someone who hates HTML (me) [01:34] So isn't there some way we can take the best of both and (ironically) merge them? [01:34] Keybuk: how does MoM get the base version when it's not available on snapshot.d.n? [01:34] Keybuk: Could others help with the interface? [01:34] that's proposal #4 [01:34] Free only part(s) of MoM, such as the UI [01:34] the UI isn't non-free [01:34] it's exactly what you see there, an HTML page that's written out by some crappy python [01:35] 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] that the DaD UI could pick up and use for tracking [01:36] what do you think about taking this to ubuntu-devel@ and also including sabdfl in the discussions? [01:36] Let's call that proposal #5 [01:37] at the moment, I don't see us coming to a conclusion in this meeting [01:37] 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] 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] 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] that is the fundamental rationale for why we've never released the code [01:38] Keybuk: I understand there's a balance here. === Pici [n=pcmacman@unaffiliated/pici] has left #ubuntu-meeting [] [01:39] sistpoty|work: it won't? [01:39] good :) [01:39] it was down due to hardware issues; which are unrelated to the software [01:39] but not unrelated to the freeness :P [01:39] From a user of the service perspective though, the why is irrelevant. [01:39] totally unrelated [01:40] if the source were open, you'd still need someone with good bandwidth and .5TB of risk [01:40] uh, of disk [01:40] :p [01:40] hahaha [01:40] bashelier: Adri2000: what do you think about MoM giving status about available packages to merge, and make DaD a frontend to that? [01:40] Yes. Getting that didn't seem to be a problem. [01:40] siretart: I also have a proposal #6 [01:41] 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] but use DaD as an UI, why not. [01:41] siretart: I think it's a good idea [01:41] ok great [01:41] let's see how that works out [01:41] It's certainly a start. [01:41] I have no problem with somebody implementing a UI for MoM (I can hardly call the current report html a UI :p) [01:41] I can ensure that the appropriate data is available [01:41] nice :-) [01:41] Keybuk: and put this UI on merges.ubuntu.com? [01:42] 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] 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] AndyP: of course [01:42] Adri2000: depending on what it's written in, sure [01:42] I would like to see if any core devs have an opinion, as the new UI could effect them as well. [01:42] is MoM all python? [01:43] geser: yes; [01:43] TheMuso: indeed [01:43] Or at the least, get some core dev's thoughts. [01:43] the usual theory with core-dev is that MoM implements the minimum necessary [01:43] Right. [01:43] we don't tend to care so much about claims, or treading on people's toes [01:43] since we're a smaller team with a much smaller based of packages [01:44] ok, are there any more open questions about this item? [01:44] Nevertheless, if the UI is going to change, wider opinions should be considered. [01:44] 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] on the options on the wiki: [01:45] #1 is probably untenable, unless you can persuade sabdfl of the benefits since it's his call [01:45] The DaD team working the UI should also consider the new/updated merges split that MoM has (and explain the difference somewhere). [01:45] #2 is also untenable, since MoM does more than just "merges"; not to mention is a much more mature solution than DaD [01:45] #3 seems reasonable from a UI POV. [01:45] ScottK: hah [01:46] ScottK: the DaD team could do a *much* better job [01:46] the difference between new/updated is "does the top entry in debian/changelog say 'gutsy'?" [01:46] Right. [01:46] 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] so often updated things have never been merged [01:47] thanks a lot Lutin, bashelier and Adri2000 for working on this [01:48] is it ok to discuss the implications of the UI changes on the mailing list? [01:48] +1 [01:48] dholbach: yes [01:48] yep [01:48] yep [01:48] Sounds good to me. [01:48] thanks a lot - please write also to the mailing list once people can test the UI [01:49] well, we need help from the MoM side [01:49] well, gotta run. see you later [01:49] bye Lutin - have a nice day [01:49] siretart: scott@ubuntu.com :-) [01:49] shall we move on to ScottK's item? [01:49] (well, when I have my mail server running again ) [01:49] Thanks for your time Keybuk. [01:49] thanks Keybuk [01:50] ScottK: https://lists.ubuntu.com/archives/ubuntu-motu/2007-June/001747.html - your stage [01:50] 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] It's clear we need to do something, particularly for server LTS support. [01:50] thankyou Keybuk [01:50] Comments? [01:50] as it is, clamav won't be getting updated definitions with 0.8x === Keybuk [n=scott@quest.netsplit.com] has left #ubuntu-meeting [""] [01:51] 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] 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] persia: that's ok, as it stands clamav can't get security fixes anyway :) [01:52] 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] ScottK: using PPAs? [01:53] 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] 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] I just checked - the diff between libclamav from dapper to gutsy is around 62K lines [01:54] persia: If there were enough resources to SRU everything that needed changing, we wouldn't be here. [01:54] dholbach: that's just the library, right? [01:54] ouch [01:54] ScottK: True. [01:54] clamav has a painful number of rdepends. [01:54] yes clamav*/libclamav [01:54] We won't get all of them. [01:55] 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] ajmitch: Yes. Definitely. [01:55] That's why the current clamav doesn't qualify for regular backports even. [01:55] up until now, it looks like added API (which is no trouble) and changed return values === juliux [n=juliux@ubuntu/member/juliux] has joined #ubuntu-meeting [01:56] it's not feasible to make a wiki page with lists of changes [01:56] ~/c [01:56] ugh === ogra [n=ogra@ubuntu/member/ogra] has joined #ubuntu-meeting [01:56] I think it'd take trial&error just trying to compile older versions with the newer clamav [01:56] dholbach: I was thinking more like a list of known to work/known not to work. [01:57] if we were to patch things === Hobbsee_ [n=mystery@ubuntu/member/hobbsee] has joined #ubuntu-meeting [01:57] 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] Heat death of the Universe would happen first. === ajmitch imagines the pain if clamav was in main [01:57] we had 21 source package or something? [01:58] ajmitch: I was thinking about that earlier. [01:58] ({build-,}depending on it? [01:58] yes, something like that [01:58] 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] TheMuso: at least then it'd be Not Our Problem :) [01:58] ajmitch: heh [01:58] lionel: That's just the latest upstream. [01:58] It'll break things. [01:59] ajmitch: try not to think about it [01:59] ah, thanks ScottK [01:59] ScottK: is dapper -> gutsy what we're looking at atm (regarding API breakage)? [01:59] No, Feisty. [01:59] Dapper -> Feisty. === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-meeting [01:59] ok [01:59] Feisty is good until the next API change... [01:59] what if we all grabbed a source package or two each and at least tried building it and see how it goes? [02:00] 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] Could we try and encourage upstream to make it easier to support older versions with defs etc? [02:00] I won't pretend I hadn't other things to do, but I see it as the only realistic option atm [02:00] ScottK: did you talk to upstream about the problem? how do they think about it? [02:00] for some build problems you could even find patches in the upstream cvs [02:00] siretart: Upgrade to the latest version. [02:00] most projects will have adapted to the new clam api [02:02] trying to get those patches to apply to the older versions could be interesting [02:02] 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] hmpf [02:03] ScottK: so they are not helpful at all. interesting [02:03] 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] I still think that backporting clamav + fixing apps is not impossible [02:04] dholbach: But you need that for all the rdpends published at the same time you publish the new clamav [02:04] dholbach: It's the synchronization that'll be the problem. [02:05] you can add Breaks: for that [02:05] 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] it's ugly, but possible [02:05] Oh? === ScottK didn't know about that one. [02:05] assuming we had 'breaks:' in dapper already [02:06] I don't think we did [02:06] adding conflicts for things like that is rather discouraged [02:06] Real Breaks: support is new for Gutsy, isn't it? [02:06] If you can do that, then it'd be doable. [02:06] "The dpkg in edgy now supports a new kind of dependency relationship, `Breaks'" [02:06] so, edgy [02:06] edgy, ok - hrm [02:06] So need to backport that first. [02:06] not going to happen [02:07] we won't upload a dpkg/apt with new features [02:07] Then that leaves the LTS release stil screwed. [02:07] we should discuss that point on the list === ScottK thinks that is a good idea for LTS +1 [02:07] primarily we should try fixing the stuff [02:08] even if the deployment of the fix is still an open issue === Hobbsee_ [n=mystery@ubuntu/member/hobbsee] has left #ubuntu-meeting [] [02:08] dholbach: But without Breaks, we'd still need fixes for everything before we backport. That's never gonna happen. [02:08] 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] I'd sign up for one or two === Zic [n=Zic@Final-Fantasy.FF-IRC.net] has left #ubuntu-meeting ["Quitte"] [02:09] First I guess we need to do testing. [02:09] I think we should offer a complete transition and attack the backport problem as a team === karimfayez [n=karim@196.202.64.204] has joined #ubuntu-meeting [02:09] OK. [02:09] some might be easy, for some we might find upstream patches, some might be real work [02:09] 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. === Czessi [n=Czessi@dslb-088-073-033-036.pools.arcor-ip.net] has joined #ubuntu-meeting [02:09] great [02:10] trying to build them in a chroot is of real help already [02:10] One related point is that the unmodified source package for clamav won't build on Dapper. [02:10] It needs the Edgy dpgk. [02:10] sorry, need to be off again... cya [02:10] see you sistpoty|work [02:10] ScottK: we should work around that [02:11] It's a two line change in debian/control. [02:11] that's fine [02:11] OK. [02:11] ok, shall we move on? [02:11] dholbach: So the action out of the meeting is for me to make a wiki page. [02:12] yes and announce it on the mailing list [02:12] ~ [02:12] ~ [02:12] ugh [02:12] ScottK: thanks a lot for insisting on making a solution happen [02:12] dholbach: One sec [02:12] I also think we should make a team of interested people. === ScottK will do that too. [02:12] ok cool [02:12] OK, now move on... [02:12] thanks again ScottK [02:13] we have a few dates to agree on [02:13] next MOTU meeting? [02:13] 2 weeks from now? same time? [02:13] Sounds good. [02:13] any objections? [02:13] that works [02:13] ok cool - who will announce it? [02:13] I'd like to see a time rotation, to be fair to those who haven't attended in a month. +/- 12 hours? [02:13] No objections, works for me. [02:13] my only objection is that two weeks aftre that, which will be the next proposed meeting, is likely during SLUG [02:14] which various members are planning to actually attend [02:14] The SLUG meeting is happening now, too [02:14] true [02:14] ok then thursday - move by 12h? [02:14] dholbach: Could we have it an hour or two later. [02:15] sure we can - we just need to agree [02:15] dholbach: 12h earlier than now? [02:15] Make the next one +14 and then go +12 after that [02:15]