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