== 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 :)
}}}