[08:56] <pitti> hey
[08:58] <mdz> is everyone here?
[08:58] <Riddell> good morning
[08:58] <mjg59> Morning
[08:58] <dholbach> hello
[08:58] <Mithrandir> ehlo
[08:58] <seb128> hi
[08:59] <ajmitch> evening
[08:59] <Kamion> morning
[08:59] <mvo> hello
[08:59] <doko> good morning
[09:00] <ogra_ibook> *yawn*
[09:00] <mdz> JaneW: ping?
[09:01] <mdz> fabbione,Keybuk,infinity,BenC,daniels: ping
[09:01] <Keybuk> yeah, I'm here ;)
[09:01] <fabbione> mdz: pong
[09:01] <JaneW> pong
[09:01] <infinity> pong.
[09:01] <JaneW> hi all
[09:02] <pitti> hey JaneW, how are you
[09:02] <mdz> does anyone know if BenC is about?
[09:02] <JaneW> pitti: good thanks and you?
[09:02] <pitti> fine
[09:02] <JaneW> mdz: he is not but I have an update from him
[09:02] <Keybuk> mdz: he only just joined #u-d
[09:02] <fabbione> mdz: he should. he knew the meeting was today
[09:02] <JaneW> mdz: I have an update from daniels and sivang too
[09:02] <mdz> Keybuk: his client rejoins every 20 minutes or so due to network problems
[09:03] <mdz> JaneW: did he send you an update because he had a reason he couldn't be here?
[09:04] <JaneW> mdz: there was no explanation or comment, just the update, - testing-server-hardware
[09:04] <mdz> JaneW: I see, please paste what you have for BenC and daniels
[09:04] <JaneW> BenC
[09:04] <JaneW> preventing-hardware-support-regressions: Build system tested, will start
[09:04] <JaneW> pushing builds this week. Afterwards will announce to the community for
[09:04] <JaneW> testing.
[09:04] <JaneW> ubuntu-server-kernel: Done (marked implemented in lp).
[09:05] <JaneW> Daniels
[09:05] <JaneW> x-roadmap: x11r7 final in, polishing xorg source package for imminent
[09:05] <JaneW> post-fl3 upload
[09:05] <JaneW> misc: broken laptop screen and dsl hilarity make for interesting
[09:05] <JaneW> availability, generally smsable within reasonable hours 
[09:05] <mdz> JaneW: what about testing-server-hardware?
[09:05] <JaneW> like I said above... his report was -testing-server-hardware
[09:05] <JaneW> I did e-mail and ask about it tho
[09:06] <mdz> oh, I thought you were saying he gave an update for testing-server-hardware specifically
[09:06] <Kamion> oh you mean "minus" rather than a bullet
[09:06] <mdz> ok
[09:06] <JaneW> yes sorry, the hyphens confussed the issue
[09:07] <mdz> ok
[09:07] <mdz> dholbach: next
[09:07] <dholbach> formal-test-plans: talked with BenC about hardware-regressions, added Instructions on how to report bugs from testing, referred to DebuggingProcedures; needs fleshing out, but i consider the pages 'ready to go' - media testing needs test files, jdub didn't want to have example-content used for this, we'll link to test files from Media/Testing
[09:07] <dholbach> this week (done): package updates, bug triage, bug day, some merges
[09:07] <dholbach> this week (todo): motu meeting, more merges, bug triage
[09:07] <dholbach> next week: bug triage, more package updates, merges, starting apt-get.org reviews
[09:07] <mdz> dholbach: what's the reason not to use example-content?
[09:08] <dholbach> mdz: jdub considers it as something "for end users" not for "developers", although i said, that i didn't want to ship all sorts of broken stuff, he didnt like the idea
[09:08] <mdz> dholbach: it's something we'll include in the default install, it's natural to use it for testing
[09:09] <dholbach> he gave me the idea of investigating in the test files of the gstreamer development team
[09:09] <mdz> ok
[09:09] <mdz> thanks dholbach
[09:09] <dholbach> de rien
[09:09] <mdz> doko: next?
[09:09] <Kamion> that sounds like it would test the things that already work?
[09:09] <doko> this week:
[09:09] <doko> - openoffice.org: 2.0.1 packages built on breezy (for breezy-updates?), start merging with unstable, renaming the packages
[09:09] <doko> - python-roadmap: python-central update, preparing snapshot version for testing
[09:09] <doko> - toolchain-roadmap: ia64 fixes, prepare for amd64 biarch update
[09:09] <doko> - other: syncs/merges, updates to new upstream versions, eclipse update (needs mozilla-dev update), half yearly ISDN updates, happy about ronne's disk space
[09:09] <Kamion> or do they have an a-priori good spread of test files?
[09:09] <doko> next week:
[09:10] <doko> - openoffice.org: sync week, i.e. dictionary and locale support (kurdish merge)
[09:10] <doko> status:
[09:10] <doko> - toolchain-roadmap: amd64-biarch (blocked on fixing a glibc amd64-i386 self-bootstrap)
[09:10] <doko> - toolchain-dapper+1: blocked by preparation of wanna-build and buildd infrastructure (no change)
[09:10] <mdz> dholbach: ping me sometime tomorrow to chat about it if there is still a question, we need to keep going
[09:10] <doko> - openoffice-gnome: not started, need an update from martink
[09:10] <doko> - openoffice-help: implemented (no change)
[09:10] <doko> - openoffice-spellchecking: not started (no change)
[09:10] <doko> - native-java-gcj: infrastructure is ready, packaging of -gcj binary packages not started
[09:10] <doko> - java-roadmap: mostly done, pending are eclipse updates (blocked by firefox-dev/mozilla-dev) and the native-java-gcj support
[09:10] <doko> - python-roadmap: proposal implemented, testing outside the archive now.
[09:10] <dholbach> mdz: ok
[09:10] <mdz> doko: renaming = openoffice.org2 -> openoffice.org?
[09:10] <doko> yes
[09:10] <mdz> is there any real value in that?  it will complicate upgrades
[09:11] <doko> we cannot support dictionaries for both versions (1 and 2), so we have to either derive for all dictionary package from debian, or make the name change as well
[09:12] <mdz> doko: is the biarch bootstrap an infinity task?
[09:12] <doko> I don't think the change will be that complicated for the end user
[09:12] <mdz> doko: please talk with mvo about how it should be handled in the upgrade tool
[09:12] <doko> mdz: currently Mithrandir is looking at it
[09:12] <Kamion> we've already gone openoffice.org -> openoffice.org2 in previous releases, going back should be relatively straightforward I'd expect
[09:12] <infinity> mdz: I took over the "fixing glibc" task from jbailey while he's off galavanting.
[09:12] <doko> mdz: will take the upgrade with mvo
[09:13] <infinity> mdz: Mithrandir had a poke last night, I'm back at it today to see where it went wrong. :)
[09:13] <Kamion> doko: are we using the python-support work being done in Debian now?
[09:13] <Kamion> (or working with them, I guess)
[09:13] <mdz> Kamion: .org -> .org2 was sort of a mess; if they now conflict that will be easier but still
[09:13] <doko> Kamion: not yet, I'm talking with Joss about merging the two
[09:13] <mdz> doko: is the help system bounty completed?
[09:14] <Kamion> ok, great, there was a lot of good analysis of the problem domain on #debian-release (which you saw, I know) so sharing that would be good
[09:14] <doko> mdz: from my point of view, yes, it does build. hope, it will not break for 2.0.2 ;)
[09:15] <mdz> doko: ok, please send me a reminder to deal with the payment
[09:15] <doko> mdz: ok
[09:15] <mdz> thanks, doko
[09:15] <mdz> fabbione: next
[09:15] <fabbione> * server-candy: system-integrity-check: fixed performance issues. Deploy is blocked on admins (rt: #723). Started other activities l
[09:15] <fabbione> ike collecting 3rd party pkgs and so on.
[09:15] <fabbione> * ubuntu-cluster: full upgrades of currently supported suites. Performed some tests and bug fixes (redhat-cluster-suite). Missing to test OCFS2.
[09:15] <fabbione> * probe-for-root-filesystem: no progress. Probably needs reassigment to somebody else.
[09:15] <fabbione> * boot-from-usb: implemented.
[09:15] <fabbione> * merges: zlib - still pending libc6-i386-dev, one merge (partman-auto-lvm) is pending but nothing scary or urgent.
[09:15] <fabbione> * last week: server-candy, ubuntu-cluster, boot-from-usb.
[09:15] <fabbione> * next week: vac. Tomorrow i will be merging the last bits around and testing OCFS2 so there will be no need for updates at the next
[09:15] <fabbione>  meeting.
[09:16] <infinity> fabbione: Is the zlib merge just pending on that as a build-dep, but otherwise done?
[09:16] <fabbione> infinity: no it needs to be done from scratch
[09:16] <mdz> Mithrandir: do you have some free bandwidth to help finish off probe-for-root-filesystem?
[09:16] <infinity> fabbione: If so, you can reassign the merge to me, give me your sources, and I'll make sure it's sorted within minutes of the biarch stuff being unbroken.
[09:16] <Mithrandir> mdz: sure, I can probably reuse some casper stuff.
[09:16] <fabbione> infinity:  i will reassign the bug, but i have no sources.
[09:16] <infinity> fabbione: Oh, if it's Real Effort(tm), then you're welcome to keep it. :)
[09:16] <Mithrandir> mdz: give me a minute to skim the spec before giving it to me
[09:16] <mdz> Mithrandir: great; the remaining piece is just to have it mount by uuid I think.  fabbione can fill you in
[09:16] <fabbione> infinity: it needs to go in before UVF and i won't be here next week
[09:17] <infinity> fabbione: Oh, then reassign it, yes.
[09:17] <mdz> fabbione: enjoy your vacation, have a good rest
[09:17] <fabbione> mdz: assuming we are going, yes thanks :)
[09:17] <fabbione> infinity: yup
[09:17] <Mithrandir> mdz: looks simple enough.
[09:17] <mdz> fabbione: you will take the time off even if you do not travel, right?
[09:17] <fabbione> Mithrandir: i will talk to you about it after the meeting
[09:17] <fabbione> mdz: yes, but i will be around if we don't travel.
[09:17] <Mithrandir> mdz: I need to get my USB hard drive back, but that should be today or tomorrow or so.
[09:18] <mdz> Mithrandir: ok
[09:18] <mdz> fabbione: thanks
[09:18] <mdz> infinity: next
[09:18] <fabbione> welcome :)
[09:18] <infinity> Last week:
[09:18] <infinity> * reducing duplication: Got MySQL 5.0 in, did some rapid bugfixing to get the packaging sane. (have joined the Debian MySQL team to make sure it gets enough polish)
[09:18] <infinity> * usplash-initramfs: Implement dirty hack for this that seems to work fine.  Eventually needs more work to do it "right" in usplash itself.
[09:18] <infinity> * misc: security, initramfs bugfixing, new LRM, new PHP, livefs changes for Mithrandir, random installability/buildability fixes in line with ongoing buildd maintenance.
[09:18] <infinity> Next week:
[09:18] <infinity> * reducing duplication: Begin rebuilding all of main to use libmysqlclient15, and kick MySQL 4.x to universe
[09:18] <infinity> * splash-down: Should have time to get this one in this week.
[09:18] <infinity> * misc: - glibc amd64-i386 biarch needs bootstrapping (but first, an irritating bug that Tollef and I spent several hours on last night needs to be hunted and killed) - need to merge subversion_1.3 for the masses (doko's request, but I agree we want it for release) - need to hunt down a kernel frequency_scaling bug that's preventing my laptop from working at full speed. :)
[09:18] <mdz> the last update has a note for us to discuss mysql 5.0; I think we're in agreement there per email conversations
  I'd say so.
[09:19] <doko> infinity: any note about db4.4, or do we go with 4.3?
[09:19] <infinity> I think we'll stick with 4.3
[09:20] <pitti> well, most packages should play well with any version, so if we need to upgrade, there are no blockers
[09:20] <infinity> Sleepycat's upstream support is good (for EVER), so there's no concern there, and 4.4 is completely untested in Debian/Ubuntu, so I don't want to risk it.
[09:20] <mdz> infinity: sounds like we can call usplash-initramfs implemented
[09:20] <infinity> But 4.3 and 4.4 both have versioned symbols, so if we need to bring it in, it probably won't hurt anyone to have a mix.
[09:20] <mdz> infinity: livefs changes includes squashfs images?
[09:20] <infinity> (I'd prefer not to have a mix)
[09:20] <infinity> mdz: Yes, we have squash.
[09:21] <mdz> cool
[09:21] <infinity> mdz: On amd64 right now, will turn it on on the other arches as soon as we've had a successful amd64 build that we've tested and know works. :)
[09:21] <mdz> Kamion: should be trivial to switch the daily builds to use squashfs, yes?
[09:21] <infinity> mdz: Already done.
[09:22] <Kamion> mdz: already done
[09:22] <mdz> is there a build available with the change?
[09:22] <Kamion> (and yes, was trivial except for me getting it wrong the first time)
[09:22] <Mithrandir> mdz: it's also a trivial per-arch switch, so we can switch ppc back to cloop if we deem unionfs too unstable
[09:22] <Kamion> mdz: on amd64, yes, but it doesn't boot yet for other reasons
[09:22] <infinity> mdz: Yes, but it's broken due to initramfs messing up.  I'll build again after the meeting.
[09:22] <mdz> ok, looking forward to testing that
[09:22] <mdz> thanks infinity
[09:22] <mdz> iwj: next
[09:23] <iwj> AutomatedTesting:  Making reasonable progress on implementation.  Tester core is about half-done now.  From last week: Apparently the IBM LTC are interested in this too and there's going to be a call (organised by Malcom Yates I think) - but this has all gone quiet.
[09:23] <iwj> Firefox maintenance:  The package isn't quite so hopeless since my upload at the end of last week.  Not working on it this week (so as to get AutomatedTesting done).
[09:23] <iwj> DefaultApplicationsFirefox: no change since last report.  I will pick this up properly when AutomatedTesting is done.
[09:23] <iwj> DeveloperDocumentation: Not started, not blocked.
[09:23] <iwj> Email and bugs backlog: moderate.
[09:23] <mdz> iwj: what remains on DefaultApplicationsFirefox again?
[09:23] <iwj> It's basically still buggy.
[09:23] <mdz> hmm
[09:23] <iwj> For example, it's hard to select a non-default application.
[09:24] <mdz> did you have a chance to do that examination of epiphany?
[09:24] <iwj> And I'm told it has a security problem with .desktop files.
[09:24] <mdz> a security problem?
[09:24] <doko> iwj: does Firefox maintenance include mozilla maintainance as well (at least until mozilla-dev is installable again)
[09:24] <iwj> Apparently you can download them and then clicky clicky gnome will run them.
[09:24] <iwj> doko: It does in the sense that I'm not doing it this week.
[09:25] <iwj> Yes, we ought to talk about mozilla.
[09:25] <seb128> right, GNOME will display the Name= of the .desktop as title and use the Icon= and run whatever command is used
[09:25] <pitti> ouch
[09:25] <iwj> I haen't looked at epiphany yet.  That definitely counts as ff maintenance :-).
[09:25] <mdz> do we need mozilla in main?
[09:25] <ogra_ibook> pitti, ouch ? 
[09:25] <seb128> pitti: we had this discussion on ubuntu-devel some months ago I think
[09:25] <ogra_ibook> pitti, you can only run existing apps
[09:25] <infinity> mdz: No, it's on its way out.  Once I split enigmail, nothing's holding it in.
[09:26] <seb128> ogra_ibook: like rm -rf ...
[09:26] <Kamion> ogra_ibook: with arbitrary arguments, and gksudo is an existing app
[09:26] <mdz> ok
[09:26] <ogra_ibook> oh, yes
[09:26] <iwj> I made nspr and nss come out of ff to try to get mozilla out of main.
[09:26] <mdz> doko: so mozilla-dev shouldn't be blocking anything, no?
[09:26] <ogra_ibook> silly me
[09:26] <pitti> seb128: hm, I don't remember that
[09:26] <doko> mdz: currently eclipse doesn't work with firefox 1.5, ok that's universe, but currently mozilla-dev isn't even installable, and firefox-dev doesn't built on amd64 and ia64
[09:27] <iwj> The 64-bit problem I will fix but not until next week.
[09:27] <mdz> ok
[09:27] <seb128> pitti: what epy issue?
[09:27] <iwj> This only affects things that embed ff.
[09:27] <ogra_ibook> pitti, in the beginning of breezy there was a discussion about autostart on CDs, i think it inherited from this one
[09:28] <mdz> iwj: do you have an ETA for something basically functional for automated testing?
[09:28] <pitti> ogra_ibook, seb128: let's discuss that in #u-devel
[09:28] <iwj> That depends on how badly ff eats me next week, I think.
[09:28] <seb128> pitti: Date: Mon, 03 Jan 2005 18:55:21 -0500, Subject: Scary .desktop behaviour
[09:28] <seb128> pitti: for the security issue
[09:28] <iwj> It's possible I'll finish it and produce something playable-with the end of this week but I'm not promising that.
[09:29] <mdz> ok
[09:29] <mdz> thanks iwj
[09:29] <mdz> Kamion: next
[09:29] <iwj> Of course there's hardly any tests.  Just one example for now that I'm playing with, sitting on my hard disk.
[09:29] <Kamion> ue-partitioning-tool: Got partman running under espresso, which makes the autopartitioning screen work. Basic progress bar handling and chaining to gparted implemented. Some bug fixes still required to make it all flow smoothly enough to use, but we're getting close. Various UI changes in partman will be needed further down the line.
[09:29] <Kamion> ubuntu-express-copy-filesystem: Tollef has made /rofs available to me with the unmodified file system; I've changed the espresso code to use it. Agreed hook scheme for casper to propagate configuration.
[09:29] <Kamion> cd-bootloader: Killed scary timeout clock, fixed some video mode menu bugs, and fixed syslinux to clear the screen properly when switching back to text mode. Still to do: help text and keymap support.
[09:29] <Kamion> misc: Helped switch live CDs to squashfs (with Adam/Tollef). I'm preparing Flight CD 3 now; exact ETA unknown but obviously ASAP; help with testing appreciated, especially for Kubuntu/Edubuntu; broken live CD boot process being fixed (we hope) at the moment.
[09:29] <Kamion> blocked: nothing much
[09:29] <Kamion> next-week: merge catch-up; get espresso up to the point where I can do a test install as long as I avoid the UI bugs (should be feasible, I think)
[09:30] <mdz> Kamion: what's the plan for the keymaps in cd-bootloader?
[09:30] <Riddell> Kamion: I should test today's dailys for kubuntu on all arches then?
[09:31] <ogra_ibook> Riddell, you should do that every day :P
[09:31] <Kamion> mdz: waiting for keymapper to switch to X keymaps (Tollef's looking at this), then scrape out the list of keymaps in much the same way as we do for locales and stick them in a menu
[09:31] <infinity> Riddell: Test the installation CDs, don't bother with Live until someone gives a go-ahead in #ubuntu-devel.
[09:31] <Kamion> Riddell: what infinity said
[09:31] <mdz> Kamion: for flight 3, please poll everyone for items which should be included in the release announcement, especially new features which are ready to test, and infrastructure which needs to be regression-tested
[09:31] <Kamion> mdz: if feasible and I have time, limit the keymap menu to those optimal for the current locale
[09:31] <Kamion> mdz: ok, I'll see if I can track down the guy who did that excellent wiki page for Flight 2
[09:32] <Kamion> DapperFlight2
[09:32] <mdz> Kamion: did the flight 2 announcement go to -users and -devel as in the past?
[09:32] <mdz> Kamion: I'm thinking we should start announcing them on -announce
[09:32] <Burgundavia> Kamion, DapperFlight3 already exists and has content going in
[09:32] <Kamion> rah, DapperFlight3 already exists
[09:32] <Kamion> Burgundavia: yeah, just noticed :)
[09:32] <dholbach_> sorry, flew out
[09:32] <Kamion> mdz: -users and -devel-announce, and I've been warning that it might be just -devel-announce in the future
[09:32] <Mithrandir> Riddell / ogra_ibook / everybody who cares about live cds: it's very, very important to keep -desktop installable, else, you won't get new live images and stuff breaks.  Also, make sure to merge seeds, since we've seen that cause live failures with user-setup.
[09:33] <Kamion> I'm vacillating on that; a lot of people on -users aren't on -devel-announce
[09:33] <Kamion> Mithrandir> merge seeds *and* upload -meta to cope
[09:33] <ogra_ibook> Mithrandir, yup, known here ...
[09:33] <Kamion> (since the live CD build process relies on -meta)
[09:33] <mdz> Kamion: a lot of the people who we want to regression-test the Flight CDs are not on -devel-announce
[09:34] <mdz> and people want to hear more on -announce
[09:34] <dholbach> fridge-devel too :)
[09:34] <Kamion> mdz: oh right, you actually mean -announce
[09:34] <infinity> Kamion: That could be changes, but since livefs builds are about the only real-world automated test we have right now to prove that the metapackages work...
[09:34] <Kamion> ok, can do; ubuntu-announce and fridge-devel then?
[09:35] <mdz> Riddell, ogra_ibook: you should be merging your seeds regularly, e.g. if you see an ubuntu-meta upload there are probably changes you need to merge
[09:35] <Kamion> infinity: yeah
[09:35] <mdz> Kamion: sounds good
[09:35] <mdz> Kamion: thanks
[09:35] <mdz> Keybuk: next
[09:35] <ogra_ibook> mdz, yup, i normally do ...
[09:35] <Keybuk> urgent-reboot-notification: Stole this spec off the nobody it was assigned to (it was linked from the udev-roadmap) and implemented it.
[09:35] <Keybuk> streamlined-boot: in progress;  have designed new readahead stuff
[09:35] <Keybuk> network-magic: ifupdown mods finished, need to test and upload.  network-manager still blocked on infinity (madwifi-ng) and jbailey (libc resolved patch)
[09:35] <Keybuk> next week: the same, but more so; merges
[09:36] <mdz> Keybuk: is there anything further in streamlined-boot which has much regression potential?
[09:36] <mdz> readahead should be pretty tame in that respect
[09:36] <Keybuk> mdz: no, it's mostly just careful adjusting and tweaking
[09:36] <Mithrandir> Keybuk: uh, you're doing evil stuff to readahead?  What's that?
[09:36] <Keybuk> *checks his board*
[09:36] <Keybuk> nope, definitely all the scary stuff is done
[09:36] <Keybuk> Mithrandir: will discuss out-of-band if you like
[09:36] <mdz> Keybuk: now that jbailey is finished with the biarch work, he shouldn't be holding a lock on glibc anymore, no?
[09:37] <mdz> should be ok to upload that patch
[09:37] <Keybuk> mdz: aye, he said he'd do it a few weeks ago, then two weeks ago, then one week ago
[09:37] <Mithrandir> Keybuk: please, since I have evil plans for readahead magic for the live cds.
[09:37] <Keybuk> :p
[09:37] <infinity> I have the current lock, actually.
[09:37] <Keybuk> Mithrandir: ok, then we should definitely talk; straight after this meeting?
[09:37] <Mithrandir> Keybuk: sure
[09:37] <infinity> Keybuk: If the patch is sane, toss it to me, and I'll put it in the "fix the bloody biarch bootstrap" upload.
[09:37] <mdz> infinity: ok, perhaps you can merge that ptach along teh way then
[09:37] <mdz> it's been discussed and agreed upon already
[09:37] <infinity> Rock.
[09:38] <infinity> Keybuk: Patch and/or bug# SVP.  My INBOX wants love.
[09:38] <Keybuk> infinity: 
[09:38] <Keybuk> http://sources.redhat.com/ml/libc-alpha/2004-09/msg00130.html
[09:38] <mdz> Keybuk: thanks
[09:38] <pitti> Keybuk: does NM have a realistic change to make it before feature freeze?
[09:38] <mdz> Lathiat: do you have anything to report on zeroconf?
[09:38] <Keybuk> pitti: depends on infinity
[09:38] <Keybuk> pitti: but I don't see why not
[09:38] <mjg59> NM is mostly a problem due to the kernel support at the moment
[09:39] <mdz> Mithrandir: next
[09:39] <Mithrandir> openoffice-amd64: no progress
[09:39] <Mithrandir> live-cd-performance: squashfs images are now produced, should speed up the cd a fair bit.  Readahead/inotify hacks are being worked on, but not there yet.
[09:39] <Mithrandir> one-true-path: no progress
[09:39] <Mithrandir> simplified-livecd: almost there.  keyboard selection is missing, espresso integration is missing
[09:39] <Mithrandir> network-authentication: no progress, doubtful it'll make feature freeze
[09:39] <Mithrandir> livecd-squashfs: implemented
[09:39] <Mithrandir> livecd-unionfs. implemented, but has problems on powerpc.  I'm working on it with BenC.
[09:39] <Mithrandir> misc: done a bit of d-i keyboard hackery so we can hopefully switch to using X keymaps in both console and X.
[09:39] <Mithrandir> Blocked on: nothing, I have plenty to do and work is progressing
[09:39] <Mithrandir> This week: Get simplified-livecd done, help Colin with Flight3, hopefully some live-cd-performance hacking
[09:39] <mdz> Mithrandir: let's drop network-authentication officially
[09:40] <Mithrandir> mdz: defer for dapper+1, I guess, not drop?
[09:40] <mdz> Mithrandir: drop from dapper, yes
[09:40] <Mithrandir> sure
[09:40] <mdz> Mithrandir: looking good, thanks
[09:40] <JaneW> mdz: I just mailed you an update from krstic...
[09:40] <mdz> mjg59: power-management-configuration?
[09:41] <mjg59> mdz: gnome-power-manager is ready, dbus is dealt with
[09:41] <mdz> mjg59: you wanted some help from pitti?
[09:41] <mjg59> The two things that are needed are (a) libpam-foreground integration (discussion on -devel didn't get very far, I'd like some more feedback) and (b) support for hal to execute privileged code
[09:42] <mdz> ok, let's talk about that after I've slept
[09:42] <mdz> mvo: next
[09:42] <ogra_ibook> mjg59, look at my dmidecode patch from dapper 
[09:42] <mjg59> (b) is basically cutting and pasting some code from hald into a daemon that runs as root and has some generic dbus glue, but I don't have time right now
[09:42] <ogra_ibook> mjg59, err, hoary, sorry
[09:42] <Kamion> Mithrandir: I think you can count casper/espresso integration as part of ubuntu-express-copy-filesystem, not simplified-livecd, for purposes of marking the latter implemented
[09:42] <mvo> Did:
[09:42] <mvo> * apt support for multiple signatures on the release file
[09:42] <mvo> * gnome-app-install fixes, supports license display/accept screen for proprietary apps and per channel apt-keys now [ThirdPartyPackages] 
[09:42] <mvo> * Dist-Upgrade tool:
[09:42] <mvo>   - more reliable meta-pkg detection/fixing missing one, should work on broken caches as well
[09:42] <mdz> Kamion: agreed
[09:42] <Mithrandir> Kamion: ok
[09:42] <mvo>   - more sanity checking after it calculated the upgrade (are the meta-pkgs still installed etc)
[09:42] <mvo>   - better error detection/handling on e.g. network problems  
[09:42] <mvo>   - logs it's activities
[09:42] <mvo>   - various hoary->breezy test-upgrades
[09:42] <mvo> [AutomaticUpgrades] 
[09:42] <mvo> * updated the apt-get.org fetching/test-building script (with dholbach) and ran a first test-run through all the stuff available on apt-get.org (291 repos scanned, 393 successful builds, 825 failed) 
[09:42] <mvo> Next week:
[09:42] <mvo> - work on the ThirdPartyPackages spec (add key support to the channels)
[09:42] <mvo> - work on the AutomaticUpgrades
[09:42] <mdz> mvo: is the dist-upgrade tool in reasonable enough shape for community testing?
[09:43] <mvo> mdz: very close. what would we test it on? hoary->breezy?
[09:43] <mdz> mvo: sure, or breezy->dapper
[09:44] <mdz> mvo: just get some exercise for the infrastructure.  write a simple howto and post to -devel-announce with a call for testers
[09:44] <mvo> yes, that sounds good, I'll do that
[09:44] <mdz> need to hurry to finish in time
[09:44] <mdz> mvo: thanks
[09:44] <mdz> ogra_ibook: next
[09:44] <ogra_ibook> * thin-client-sound: implemented (thank you pitti, for the gstreamer magic!)
[09:44] <ogra_ibook> * thin-client-local-devices: dropped
[09:44] <ogra_ibook> * thin-client-memory-usage: worked on forced 16bit xorg mode (not preseedable, as most of the xorg settings). looked at nbd and the implementation for network swapping.
[09:44] <ogra_ibook> * thin-client-faster-startup: worked on the initscript handling, did more initramfs testing.
[09:44] <ogra_ibook> * gnome-screensaver-default-image: no progress, still need pictures ....
[09:44] <ogra_ibook> * general: done some further work on ltsp-build-client and ltsp-update-kernels (yaboot and kernel stuff) for ppc, getting edubuntu-artwork in shape, preparing for flight3, did some more dhcpd tests for the --next-server stuff
[09:44] <ogra_ibook> * next week: flight3 testing, missed the nfs timeout bugsqashing i had planned for last week, will do it this week, last xscreensaver merge work before UVF, getting all the local bits and pieces of ltsp into shape.
[09:45] <mdz> ogra_ibook: any leads on the nfs timeout issue?
[09:45] <ogra_ibook> not yet
[09:45] <ogra_ibook> as i said, i missed the time for debugging 
[09:45] <mdz> ogra_ibook: if you haven't already, arrange to talk with BenC about it
[09:45] <ogra_ibook> since its a bug its not critical for feature freez
[09:45] <mdz> it seems awfully like a kernel issue
[09:45] <Riddell> ogra_ibook: what happened with thin-client-local-devices?
[09:45] <ogra_ibook> Riddell, postponed
[09:46] <mdz> Riddell: the spec was never complete, it needs much more discussion and design woru
[09:46] <mdz> work
[09:46] <ogra_ibook> mdz, yes, i suspect the same
[09:46] <mdz> ogra_ibook: thanks
[09:46] <mdz> pitti: next
[09:46] <pitti> last week: caught up with a lot of security updats, caught up with bug triage, lots of urgent bug fixes, main inclusion reviews
[09:46] <pitti> no progress on specs (ENOTIME), but for JaneW's overview I'll give the current status of the non-implemented specs:
[09:46] <pitti> firewall: long-outstanding bounty proposal, I do not know about mdz's approval status; no news from carstenh for quite a while now
[09:46] <pitti> automatic-printer-conf: DONE: dynamic USB printer recognition implemented due to cupsys 1.2beta; TODO: gnome UI integration requires to evaluate hal-cups-utils from Fedora, port it to Ubuntu, do integration and tests; no blocks, no progress
[09:46] <pitti> langpacks-desktopfiles: DONE: implemented for .desktop files; PLAN: outstanding for .server files (will try to look into this next week)
[09:46] <pitti> plan next week: get an agreement about sudo help approach in TB, last steps to throw mozilla out of main
[09:47] <mdz> pitti: is there an actual proposal for firewall?
[09:47] <mdz> scope of work and price?
[09:47] <pitti> mdz: hm, carsten sent one ages ago, I have to look again (don't remember any more)
[09:47] <mdz> pitti: ok, if it's something I lost track of over the holidays, please resend
[09:48] <pitti> mdz: no price, but scope etc. is there
[09:48] <mdz> pitti: thanks
[09:48] <mdz> seb128: next
[09:48] <seb128> dapper-desktop-plan: default panel configuration changed, "add to panel" changes will be uploaded today
[09:48] <seb128> other: load of bug triage, pushed some GNOME changes/patches upstream before the feature freeze, GNOME changes (pygtk splitted to pyobject/pygtk, etc)
[09:48] <seb128> next-week: dapper-desktop-plan, continue bug triage
[09:49] <mdz> seb128: which other parts of dapper-desktop-plan are still pending?  can you estimate the completion of the spec?
[09:49] <mdz> seb128: I saw that mjg59 posted some concerns which I think were aimed at dapper-desktop-plan, please make sure that sabdfl sees and responds
[09:49] <seb128> 40% complete when the add to panel changes land today
[09:50] <seb128> that's menus-revisited
[09:50] <seb128> (mjg59 mail)
[09:50] <mdz> oh, even so
[09:50] <seb128> yeah, will do that
[09:50] <mdz> thanks seb128
[09:50] <mdz> sivang: ayt?
[09:50] <seb128> for dapper-desktop-plan there is some applet hacking that should be easy, and then the gdm changes
[09:51] <mdz> Riddell: next
[09:51] <Riddell> done: KDE security fixes, shipping breezy CDs, bug day recruitment and support, CD testing, final few libstdc++ transition packages
[09:51] <Riddell> zeroconf: avahi support added
[09:51] <Riddell> kubuntu-express: browsing the current sources, touching up my pykde skills
[09:51] <Riddell> kubuntu-roadmap-dapper: CKJ support now complete (question, should scim etc go into main?)
[09:51] <Riddell> next week: flight 3, qtparted changes for kubuntu-express, sudo wrapper
[09:51] <mdz> Riddell: I'm happy for scim to enter main given inclusion reports
[09:51] <mdz> Riddell: I'm less clear on what we need to do with it once it's there, beyond installing it by default
[09:52] <Riddell> mdz: we have them so I'll link them from the to be reviewed list
[09:52] <doko> we be interesting to know how to test/use it ...
[09:52] <pitti> Riddell: I have a pending main inclusion report for scim
[09:52] <Riddell> I don't know if it should be installed by default since most users don't use it, maybe ship only
[09:52] <mdz> I've seen some email from a fellow who is interested in helping us with input methods
[09:53] <mdz> I'll see if he can provide some instruction about testing/using it
[09:53] <ogra_ibook> oh, main inclusion, any chance i see gobby reviewed pitti ? its a listed goal for edubuntu 
[09:53] <Kamion> Riddell: the gparted --installer changes are (back) in now; emulating that general approach for kubuntu-express would probably be good
[09:53] <Riddell> Kamion: that's the plan
[09:53] <pitti> ogra_ibook: no problem security wise, I'm just scared of bug reports that complain about broken documents :)
[09:53] <Kamion> Riddell: does Qt support anything like GtkPlug/GtkSocket for inter-process widget embedding?
[09:53] <ogra_ibook> pitti, forward them to me :) 
[09:54] <Riddell> Kamion: I'm not sure exactly what that is, KDE has kparts
[09:54] <mvo> Riddell: the dist-upgrade tool is designed to make it easy to plug a new interface to it, we should talk about this after the meeting
[09:54] <Kamion> Riddell: http://developer.gnome.org/doc/API/2.0/gtk/PlugSocket.html
[09:54] <dholbach> Riddell: wasn't there a blog entry recently about embedding qt in gtk and vice versa?
[09:55] <mdz> Riddell: thanks for the update
[09:55] <mdz> JaneW: any questions or concerns for the last 5 minutes?
[09:55] <mdz> or anyone else?
[09:56] <JaneW> I was going to raise the TC local devices issue, but after mails earlier I think it's not necessary
[09:56] <JaneW> I'll give sivang's update...
[09:56] <mdz> JaneW: I am going to throttle flint the next time I see him
[09:56] <JaneW> mdz: thank-you ;)
[09:56] <JaneW> Sivan
[09:56] <JaneW> Updates:
[09:56] <JaneW> 1)Already working on the main backup application GUI together with finishing utility components. 
[09:56] <JaneW> 2)Finished the media device detection code. (to offer a user to choose among available media targets to backup to).
[09:56] <JaneW> 3)I expect to be able to finish the project before FF which is 23rd February. That should give me a month to QA and test the work. (As well as by other community members)
[09:56] <JaneW> Todo:
[09:56] <JaneW> 1) Finish main application GUI and startup stuff.
[09:56] <JaneW> 2) Write code to allow notification through notify-daemon about backup intervals. I had set up wrapping up libnotify for python usage for this, but this may be dropped if time does not allow it and I will use the gross hack of having pre-made C binaries per the 2 notificatios I need there instead.
[09:56] <JaneW> 3) Code the dar integration bits.
[09:57] <JaneW> 4) Code the mkisofs / cd burning bits.
[09:57] <mdz> ok
[09:57] <JaneW> sorry the above is for: home-user-backup
[09:57] <mdz> right
[09:57] <mdz> ogra_ibook: how does edubuntu look for flight 3?
[09:57] <JaneW> please could everyone make sure their specs are up to date in LP
[09:57] <mdz> Riddell: and kubuntu?
[09:58] <JaneW> I know most ppl have been good at updating statuses etc
[09:58] <JaneW> also not everyone finished the est dev days and expectation of delivery, we should still try to complete that
[09:58] <Mithrandir> I wish launchpad had a way to say "this is 50% completed"
[09:58] <mdz> JaneW: have you made progress with someone on the LP team as far as getting a spec report export implemented in launchpad?
[09:58] <ogra_ibook> mdz, should be fine ... -desktop was broken for a while, i'm just pulling the first isos
[09:58] <Mithrandir> some sort of rudimentary progress tracking.
[09:58] <Riddell> mdz: should be fine, I just need to test the CDs
[09:58] <JaneW> last thing, the meeting for the week of the sprint, can we make it a sane local time instead of 2am?
[09:58] <Mithrandir> now, stuff jumps from "approved" to "done".
[09:59] <Kamion> JaneW: should the estimated dev days be remaining or from-start-of-project?
[09:59] <mdz> Riddell: have you tested some recent dailies?
[09:59] <pitti> Mithrandir: you can use the whiteboard
[09:59] <JaneW> mdz: no I haven;t taken that further, is everyone happy with the report format and content?
[09:59] <JaneW> Mithrandir: I did ask for a WIP at least
[10:00] <mdz> JaneW: I'd prefer that the old and new statuses were in separate cells
[10:00] <Kamion> JaneW: start of the working day would be good
[10:00] <mdz> it's hard to read as is
[10:00] <Kamion> (for sprint meeting)
[10:00] <JaneW> Kamion: I think from start to finish for consistency
[10:00] <Kamion> JaneW: ok, so what should we be updating?
[10:00] <Riddell> mdz: been testing lives, which have had the authentication issue, should be working ok now after seed merge but yet to test today
[10:00] <Kamion> likelihood of completion?
[10:00] <Kamion> (and I agree, it gets a bit mad otherwise)
[10:00] <pitti> JaneW: hm, I adapted mine to be the 'days left', not the 'total days'
[10:00] <mdz> JaneW: we also need that access control fix for targeting specs to a release, so that launchpad can be authoritative for that
[10:00] <mdz> JaneW: please follow up with kiko, find out who we should talk to about spec tracker stuff since mark will be too busy
[10:01] <mdz> and that's a wrap
[10:01] <mdz> thanks, everyone
[10:01] <JaneW> Kamion: expectation of delivery (i.e. will the thing get done?) and estimated dev days (how long it;s expected to take)
[10:01] <mdz> and good night
[10:01] <fabbione> night mdz
[10:01] <mvo> good night mdz 
[10:01] <fabbione> cya later
[10:01] <JaneW> mdz: ok I'll pick it up again...
[10:01] <ogra_ibook> night mdz
[10:01] <dholbach> good night mdz
[10:01] <JaneW> last thing, the meeting for the week of the sprint, can we make it a sane local time instead of 2am?
[10:01] <pitti> thanks folks, bye
[10:01] <Kamion> 09:00 < Kamion> JaneW: start of the working day would be good
[10:02] <pitti> JaneW: yes, pleeeeease :)
[10:02] <JaneW> Kamion: ah right good, I opted for 10am, shall we make it 9am?
[10:02] <Kamion> I imagine we'll be doing start-of-day things anyway?
[10:02] <Kamion> 9am+coffee = 10am, so I don't mind
[10:02] <JaneW> we'll need to decide if it's verbal, with report, or IRC as usual
[10:03] <fabbione> i suggest verbal
[10:03] <infinity> verbal = violence.
[10:03] <sivang> mdz: here now
[10:03] <JaneW> depends how many on-line ppl want to listen in
[10:03] <fabbione> so we can kill each other
[10:03] <fabbione> :)
[10:03] <infinity> Which is fine, so long as I make sure I'm not blocking anyone by then.
[10:03] <fabbione> infinity: ++
[10:03] <Burgundavia> JaneW, please keep it online
[10:03] <sivang> ah bad, too late ..:-/
[10:03] <mvo> verbal has the disadvantage that external people can't follow it 
[10:03] <infinity> Point.
[10:04] <dholbach> i think we'll have quite a lot of verbal interaction anyway :)
[10:04] <JaneW> Burgundavia: I am happy to means I can  cut 'n paste - less typing for me!
[10:04] <ogra_ibook> why keeping it online, the reports are public
[10:04] <infinity> Online also makes it easier to hack in the background when you're not the focus of attention. :)
[10:04] <Kamion> verbal+minutes is fine too, but I think the minuter would be somewhat overloaded with the volume of information in a distro team meeting
[10:04] <infinity> It's like two hours for the price of one!
[10:04] <Mithrandir> verbal with paintball guns sounds good.  So you shoot people if they block you and stuff.
[10:04] <Kamion> ogra_ibook: the conversation's useful too ...
[10:04] <Seveas> pitti, we sort of had that on the Ubuntu NL spurt, but with 7 people ;)
[10:04] <JaneW> pitti: we do that normally anyway!
[10:04] <Kamion> Mithrandir++
[10:04] <pitti> JaneW: I don't :)
[10:05] <ogra_ibook> Kamion, true ...
[10:05] <dholbach> guys, you are agressive - didn't you have time to relax?
[10:05] <mvo> HUG DAY!
[10:05] <pitti> Mithrandir: you should keep them alive enough for them to be able to finish the stuff you wait for
[10:05] <dholbach> tsssss
[10:05] <Mithrandir> pitti: paintballs don't kill.  They just hurt.
[10:06] <pitti> JaneW: 'rubber rocket', I see. The Orion shop calls them a bit differently :)
[10:06] <JaneW> LOL
[10:06] <sivang> JaneW: Thank you for reporting for me, in my absence :)
[10:06] <pitti> JaneW: anyway, 10am is probably sane, after the initial talks and tea
[10:06] <dholbach> JaneW: i was reminded on sabdfl's latex lotion the moment you talked about it ;)
[10:07] <ajmitch> dholbach: hehe :)
[10:07] <sivang> ah ah
[10:07] <pitti> ok, back to work. thanks to everybody
[10:07] <JaneW> bye
[10:07] <JaneW> pitti: what's ENOTIME?
[10:08] <Mithrandir> JaneW: no time available
[10:08] <mvo> JaneW: it just means Error No Time
[10:08] <JaneW> oic, I was thininking 'not enough time' or suchlike
[10:08] <Kamion> pretty much the same
[10:08] <dholbach> JaneW: E<BOLDLETTERS> are usually made up "error messages" :)
[10:08] <JaneW> ta
[10:08] <Kamion> (or real libc error codes, sometimes ...)
[10:09] <Kamion> (e.g. my house is ENOSPC)
[10:09] <JaneW> EFNF
[08:56] <\sh> evening gentlemen
[08:56] <LaserJock> hi \sh
[08:57] <sistpoty> hiho
[08:57] <lucasd> hello :)
[08:57] <lucas> hello
[08:58] <lucas> Should I announce the meeting on #ubuntu-motu and #ubuntu-devel ?
[08:58] <raphink> hop
[08:58] <raphink> hi guys :)
[08:59] <dholbach> hello
[08:59] <sistpoty> hey dholbach
[08:59] <raphink> :)
[08:59] <chninkel> hi
[08:59] <dholbach> lucas: yeah, although #ubuntu-motu should be aware of it :)
[09:00] <raphink> hopefully
[09:00] <sistpoty> do we want to start?
[09:00] <\sh> it's 20:00 UTC...welcome ladies and gentlemen
[09:00] <zul> heylo
[09:00] <ogra_ibook> :)
[09:00] <sistpoty> hey ogra_ibook
[09:01] <raphink> hi ogra_ibook 
[09:01] <raphink> hi zul 
[09:01] <sistpoty> ok, anyone volunteering to do the minutes?
[09:01] <lucas> * silence *
[09:02] <raphink> * more silence *
[09:02] <Riddell> like a Quaker meeting this
[09:02] <raphink> hi Riddell 
[09:02] <\sh> sistpoty: i'll do it when it's ok if I send later this week :)
[09:02] <sistpoty> cool, thx \sh
[09:03] <sistpoty> let's start with discussion... who made the first point /usr/share/common-licenses/GPL vs /usr/share/common-licenses/GPL-2?
[09:03] <siretart> hu folks
[09:03] <sistpoty> hi siretart
[09:03] <raphink> I did sistpoty 
[09:03] <Riddell> start with names no?
[09:03] <sistpoty> then go ahead, raphink ;)
[09:03] <\sh> yes
[09:03] <\sh> please state your names
[09:04] <dholbach> wow, full house
[09:04] <sistpoty> :)
[09:04] <lucas> lrwxrwxrwx 1 root root     5 2005-10-02 23:23 GPL -> GPL-2
[09:04] <lucas> -rw-r--r-- 1 root root 17989 2005-06-16 16:32 GPL-2
[09:05] <lucas> what do you suggest, raphink ?
[09:05] <raphink> the first poing comes from some talks on #ubuntu-motu about the license link in debian/copyright. This seems like a small issue but not everbody seem to have tyhe same opinion of it. I looked in Policy for this and found only notices about the GPL file, not GPL-2
[09:05] <raphink> so it seems like GPL is a link to the latest version of GPL, currently GPL-2
[09:05] <raphink> I wanted to point that out since many seem to belive that packages licensed under "GPL v2 or later" should point to GPL-2
[09:05] <raphink> this doesn't matter so much now
[09:06] <raphink> but GPL-3 is to be out in a matter of months, if not weeks now
[09:06] <raphink> so we'd better have clear policy on this link in copyright imo
[09:06] <lucas> GPL v3 won't be released before a year or so
[09:06] <lucas> it's only the reviewing process that starts next monday
[09:06] <raphink> lucas : my point was mainly about REVU so far since we also release new packages ;)
[09:07] <raphink> ok
[09:07] <raphink> :)
[09:07] <ogra_ibook> i think it should be rised at the TB
[09:07] <sistpoty> ogra_ibook++
[09:07] <raphink> ok
[09:07] <raphink> next week then ;)
[09:07] <dholbach> yeah, i agree with ogra
[09:07] <ogra_ibook> put it on the agenda there :)
[09:08] <siretart> even better :)
[09:08] <Riddell> are we under disagreement?
[09:08] <\sh> well...
[09:08] <crimsun> if in doubt we should be consulting /usr/share/doc/$foo/copyright anyhow, but yes, the issue's one for the TB (though we should try and minimize deviation from Debian)
[09:08] <\sh> I'm not convinced about this paragraph:
[09:08] <\sh> Each version of the License is given a distinguishing version
[09:08] <\sh> number. If the Document specifies that a particular numbered version
[09:08] <\sh> of this License "or any later version" applies to it, you have the
[09:08] <\sh> option of following the terms and conditions either of that specified
[09:08] <\sh> version or of any later version that has been published (not as a
[09:08] <\sh> draft) by the Free Software Foundation.
[09:08] <crimsun> err, not /usr/share/doc/$foo/copyright but COPYING in the source
[09:08] <raphink> hmm
[09:09] <lucas> \sh: what do you mean by "not convinced" ?
[09:09] <raphink> do I had it to the TB agenda ?
[09:09] <raphink> s/had/add/
[09:09] <\sh> lucas: it gives upstream a choice 
[09:09] <lucas> basically, a package stating GPLv2 or later should point to GPL, while a package stating GPLv2 should point to GPL-2
[09:10] <ogra_ibook> raphink, thats the way to get it to the TB
[09:10] <sistpoty> \sh: imo it also gives distributors a choice, but IANAL
[09:10] <lucas> \sh: it gives the user or the distributor a choice
[09:10] <\sh> lucas: to say: only GPLv2 or "later == GPLv3"
[09:10] <Riddell> does anyone disagree with use GPL-2 for programs that are strictly GPL 2 and use GPL symlink for programs that are GPL 2 or later?
[09:10] <ogra_ibook> raphink, i dont think its a MOTU specific issue ...
[09:10] <\sh> sistpoty: well...the debian/dir is licensed by the maintainer in my POV
[09:10] <raphink> indeed ogra_ibook 
[09:10] <sistpoty> good point \sh
[09:10] <sistpoty> but let's defer that to TB and move on... agreed?
[09:10] <crimsun> Riddell: I don't disagree, but it's a matter for the TB
[09:10] <\sh> so we have to deal with two license issues here
[09:11] <siretart> next!
[09:11] <\sh> sistpoty: agreed :)
[09:11] <ogra_ibook> \sh, nope, we dont
[09:11] <sistpoty> ok, next point are the todo's doko_ has for us...
[09:11] <\sh> ogra_ibook: to go on :()
[09:11] <ogra_ibook> \sh, the whole distro has ;)
[09:11] <sistpoty> hehe
[09:12] <raphink> huhu
[09:12] <sistpoty> they are basically 1) packages still depending on libstdc++5 (gcc-3.3)
[09:12] <sistpoty> which ftbfs
[09:12] <sistpoty> I once started a wiki page MOTUStdc++-transition...
[09:12] <dholbach> how is the status there? how much is left?
[09:12] <sistpoty> but I don't know about the current state of these
[09:13] <\sh> sistpoty: vn4 / im-sdk are not gcc4 compatible somehow
[09:13] <sistpoty> \sh: we need at least g++-3.4
[09:13] <siretart> sistpoty: please allow me a foolish question: why do packages build depending on gcc-3.3 ftbfs?
[09:13] <siretart> I mean why still have gcc-3.3 around!
[09:13] <\sh> sistpoty: i think the page is broken..when I looked only 1 or 2 packages were left...and then we recevied again a mail from doko..so I have a look
[09:13] <sistpoty> siretart: obviously they don't b-d on gcc-3.3, but didn't get ever rebult
[09:14] <siretart> ah. I see
[09:14] <sistpoty> doko_: reading this?
[09:14] <\sh> siretart: because it was the time in breezy, when not all packages were tested to be build with gcc-3.4/4.0
[09:14] <raphink> sistpoty: so then? how is it a work for MOTU to rebuild them ? 
[09:14] <lucas> so it's just about uploading a -1build1 version so they gets rebuilt ?
[09:14] <siretart> sistpoty: so can we assume that all those FTBFS do also apply in debian?
[09:14] <sistpoty> \sh: I'm not quite clear (in his mail, doko_ wrote, that the lists are rebuilt daily, but I don't think they are)
[09:15] <sistpoty> lucas: no
[09:15] <raphink> what has to be done with these packages then?
[09:15] <sistpoty> raphink, lucas: they ftbfs... we need to make them build again
[09:15] <siretart> lucas: they most probably where tried to be rebuild but failed
[09:15] <lucas> ok
[09:15] <\sh> lucas: definetly not :)
[09:15] <raphink> k
[09:15] <sistpoty> iirc they where all uloaded with -nbuildx
[09:15] <\sh> and one of the biggest problem with this is, some packages are not well maintained anymore
[09:15] <lucas> so this item can be merged with the FTBFS check later ;)
[09:16] <sistpoty> lucas: it could, but should at least get some attention now
[09:16] <sistpoty> I tried some packages, but they are horribly broken, so we might want to check for a new upstream version
[09:16] <dholbach> yeah, upstream versions asap :)
[09:16] <raphink> ok
[09:17] <raphink> for each of them?
[09:17] <dholbach> only if it helps and it is feasible
[09:17] <raphink> ok
[09:17] <sistpoty> raphink: if it makes them compile ;)
[09:17] <dholbach> some upstreams have stopped working too, i fear
[09:17] <\sh> raphink: try to build them first with actuall toolchain, if this is not working out, try gcc-3.4 and if this is not working new upstream check and try to build it :)
[09:17] <dholbach> uvf is in one week
[09:17] <\sh> s/actuall/actual/
[09:18] <dholbach> we will have exceptions, but not too many
[09:18] <raphink> yep \sh understood :)
[09:18] <sistpoty> how do we want to handle these packages? try again with the wiki-page?
[09:18] <crimsun> if you come across mythtv, discard it. I'm pulling from -fixes svn branch to make it build with g++-4.0.
[09:18] <sistpoty> s/handle/organize handlinge/
[09:18] <siretart> sistpoty: they aren't that many, I think a wiki page might be feasible in this case (and you know how much I hate wikis for that!)
[09:18] <sistpoty> crimsun: bah... I'm just about to fix mythplugins... 
[09:18] <\sh> well, I can take the new allocator transition list 
[09:19] <sistpoty> \sh: they seem to be ftbfs-candidates as well
[09:19] <siretart> sistpoty: and mythtv needs a lot of love, it is currently orphaned :(
[09:19] <\sh> sistpoty: doesn't matter...but most of hte packages don't need a rename because they're apps :)
[09:19] <dholbach> i think for the following week we should concentrate on updating/merging where we need it - what do you guys think?
[09:20] <sistpoty> dholbach++
[09:20] <raphink> +1 dholbach 
[09:20] <raphink> some guys will shout on REVU that their packages are not being reviewed ;)
[09:20] <dholbach> if there are fixes we can get from cvs, we should get them in too
[09:20] <\sh> well..merging/updating/new apps are prio 1 i think until the 19th
[09:20] <dholbach> raphink: NEW packages have time until feature freeze (= Feb 23)
[09:21] <raphink> dholbach: what exactly is frozen on 19th then?
[09:21] <lucas> can't we postpone UVF for universe ?
[09:21] <dholbach> new upstream versions
[09:21] <\sh> lucas: no
[09:21] <dholbach> the spec explicitly say no
[09:21] <crimsun> lucas: no, that was a huge issue last release
[09:21] <siretart> lucas: we have UVF for a reason
[09:21] <sistpoty> ok, seems like we are already moving to the next point on the agenda... uvf for universe
[09:21] <\sh> lucas: we decided at ubz to go with the release schedule this time more strictly
[09:22] <lucas> raphink: MoM stops working, so new packages in Debian don't get imported into Ubuntu
[09:22] <sistpoty> dholbach: do you know if mom will be running until the last day of UVF?
[09:22] <dholbach> sistpoty: we should Keybuk about that
[09:22] <dholbach> i think it'll have to be fixed for Malone
[09:22] <dholbach> although... that doesn't matter for universe
[09:22] <dholbach> forget what i said
[09:22] <\sh> dholbach: well...for universe it never filed any bugs in bugzilla :) so we don't need a fix :) right now
[09:22] <dholbach> we should kindly ask him
[09:23] <sistpoty> dholbach: if it *is* running till the last day, we definitely won't be able to "hand"-merge last runs packages
[09:23] <dholbach> we can just talk to him
[09:23] <\sh> actually for the remaining merges we have time to the 2nd of February
[09:23] <\sh> https://wiki.ubuntu.com/DapperReleaseSchedule
[09:23] <raphink> so on the 19th automatic merges stop
[09:24] <raphink> but we keep merging manually till the 2nd of feb ?
[09:24] <\sh> raphink: there are no automatic merges :)
[09:24] <raphink> right?
[09:24] <siretart> and hey, UVF is not the end of the world. if you can show that a new version from debian fixes some important problem, we can still sync it
[09:24] <sistpoty> ah, good to know \sh
[09:24] <\sh> raphink: only mom stops...and we have to stop on the 2nd
[09:24] <raphink> \sh: I mean syncs
[09:24] <lucas> raphink: right
[09:24] <siretart> but we won't focus on merging anymore. we focus on bugfixing. of a bug can be fixed by a sync, even better!
[09:24] <\sh> raphink: the auto sync robot is stopping, MoM is not running anymore
[09:25] <sistpoty> ok, how will we handle uvf-exceptions? 
[09:25] <raphink> yep got that :)
[09:25] <sistpoty> same as last year: get dholbach's or ogra_ibook's ok?
[09:25] <raphink> and we only sync as manual requests if syncs fix bugs
[09:25] <\sh> sistpoty: I think the same way as we handle it in main..ask mdz or kamion 
[09:25] <siretart> sistpoty: I propose the same procedure as with breezy
[09:25] <sistpoty> s/last year/breezy/ 
[09:25] <sistpoty> siretart++
[09:25] <siretart> sistpoty: ogra appointed 2 or 3 delegates who proxied/approved sync requests
[09:25] <dholbach> i think they will have better things to do
[09:26] <dholbach> we should raise the topic in the TB meeting
[09:26] <siretart> yes
[09:26] <ogra_ibook> sistpoty, there was a documment anywhere on the wiki from the UBZ BOF where its outlined
[09:26] <\sh> dholbach: we should :) 
[09:26] <dholbach> since this was not explicitly mentioned in the spec
[09:26] <ogra_ibook> dholbach, it was mentioned
[09:26] <ogra_ibook> Kamion showed me the part
[09:26] <dholbach> ogra_ibook: who approves exceptions?
[09:27] <ogra_ibook> as it sounded there should be no exceptions ... 
[09:27] <\sh> ogra_ibook: 
[09:27] <\sh> We have found in the past that newer universe packages tend to demand newer dependencies in main. Accordingly, universe will enter UpstreamVersionFreeze at the same time as main, in order to reduce dependency tension between newer versions of packages in main and universe. The exact details of sync and merge schedules will be the decision of the MOTU team. As in main, syncs and merges to universe after UVF must be verified to build and in
[09:27] <\sh> anted for new or updated dependencies).
[09:27] <ogra_ibook> apart from that it will be as in all releases before, Kamion and mdz i think
[09:27] <dholbach> ogra_ibook: you're wrong
[09:27] <\sh> https://wiki.ubuntu.com/DapperReleaseProcess
[09:27] <dholbach> "no exceptions" is wrong.
[09:27] <siretart> ogra_ibook: come on, we will need exceptions, if we don't want to diverge totally!
[09:27] <ogra_ibook> siretart, sure
[09:28] <dholbach> Jan 06 13:50:53 Kamion        dholbach: https://wiki.ubuntu.com/DapperReleaseProcess explicitly contradicts that, but we'll be flexible with exceptions for universe
[09:28] <ogra_ibook> siretart, but at a very minimal base as i understand the above \sh just pasted
[09:28] <dholbach> there you go
[09:28] <crimsun> well, since we need a decision, how do dholbach and \sh feel about being the proxies? (Don't mean to exclude ogra, but I presume he'll be busy with Edubuntu)
[09:28] <dholbach> crimsun: let's raise the topic at the TB
[09:28] <\sh> the biggest problem is "new dependencies in main for universe packages" this we should avoid...for universe itself, we can get it straight, and we can discuss it with mdz/kamion 
[09:28] <dholbach> and sort out the process explicitly
[09:28] <lucas> what do we do regarding REVU ?
[09:29] <ogra_ibook> you can abuse me after feature freeze again ... i'll have more time then :)
[09:29] <lucas> we just stop uploading packages on the 19th ?
[09:29] <ogra_ibook> lucas, new versions, yes
[09:29] <ogra_ibook> lucas, exceptions need approval and extra review
[09:29] <lucas> (this would lower the pressure on the MOTUs and let them concentrate on bugfixing)
[09:29] <crimsun> dholbach: certainly; it would be nice to say "here are our proxies" when approved
[09:30] <lucas> ogra_ibook: totally new packages are no longer accepted ?
[09:30] <siretart> I'd really require a malone bugnr for each exception this time
[09:30] <raphink> ogra_ibook: I understnad new packages are not considered new versions ?
[09:30] <dholbach> lucas: https://wiki.ubuntu.com/DapperReleaseProcess
[09:30] <dholbach> Feature Freeze is the date
[09:31] <sistpoty> do we have an agreement for exceptions already?
[09:31] <crimsun> raphink: right, 1.2.3-(X+1) is fine, but 1.2.(Y+1)-X is not
[09:31] <ogra_ibook> sistpoty, TB
[09:31] <sistpoty> ok
[09:31] <raphink> between UVF and FF, we keep getting new packages in, but not getting new versions of existing packages from Debian, alright?
[09:31] <siretart> from DapperReleaseProcess: The exact details of sync and merge schedules will be the decision of the MOTU team.
[09:31] <\sh> regarding new packages: this paragraph is important
[09:31] <\sh> Since entirely new packages in universe are relatively safe and attract a number of new developers, they will be liberally admitted until FeatureFreeze if they do not require additional or newer dependencies.
[09:31] <raphink> crimsun: I guess unless Y=-1
[09:32] <raphink> ok
[09:32] <raphink> :)
[09:32] <raphink> so REVU is still up till FF
[09:32] <dholbach> "new versions" are cumbersome
[09:32] <siretart> yes
[09:32] <sistpoty> \sh: ok, then we can defer the point "packages on revu" (I have already some thoughts about it, but let's defer this)
[09:32] <dholbach> you can always pack a 3MB patch in debian/patches
[09:32] <\sh> dholbach: go away :)
[09:33] <raphink> lol
[09:33] <ogra_ibook> dholbach, i was told that nobody will approve that anymore in breezy :)
[09:33] <dholbach> so try to have this in mind, we really want minimal changes :)
[09:33] <crimsun> that way madness lies (cf. vlc)
[09:33] <LaserJock> next item?
[09:33] <dholbach> yeah :)
[09:33] <sistpoty> LaserJock++
[09:33] <lucas> ok, I think the topic was covered. Shall we move on to FTBFS packages ?
[09:33] <siretart> so, did we agree on the proxies yet?
[09:33] <raphink> yep
[09:34] <siretart> please repeat them
[09:34] <sistpoty> siretart: deferred to TB, as I understood it
[09:34] <\sh> siretart: TB ... and remove me from the list :)
[09:34] <siretart> sorry, please not the TB
[09:34] <ogra_ibook> sistpoty, the called proxies were \sh and dholbach 
[09:34] <siretart> we should at least make proposals for the TB
[09:34] <lucas> who is in charge of forwarding items to the TB ?
[09:34] <\sh> ogra_ibook: the called proxies were siretart and dholbach
[09:34] <ogra_ibook> but to get the right conact people we said TB
[09:34] <ogra_ibook> \sh, and you :)
[09:35] <raphink> TB is on 17th right?
[09:35] <\sh> ogra_ibook: no...because of the private matters
[09:35] <lucas> 15th I think
[09:35] <lucas> but not sure
[09:35] <siretart> ogra_ibook: \sh doesn volunteer, and me alone is crazy
[09:35] <siretart> ogra_ibook: I'd propose sistpoty as proxy
[09:35] <lucas> ah no 17
[09:35] <dholbach> i trust enough in siretart, sistpoty and slomo_ to have them decide too
[09:35] <\sh> ogra_ibook: right now, I'm more a SPoF
[09:35] <siretart> and slomo, right
[09:35] <raphink> ;)
[09:35] <ogra_ibook> dholbach++
[09:35] <raphink> lucas: better for you to know and not miss it ;)
[09:36] <lucas> :)
[09:36] <dholbach> crimsun too
[09:36] <raphink> ;)
[09:36] <ogra_ibook> dholbach++
[09:36] <dholbach> but we should decide on the number of people proxying in the TB meeting
[09:36] <ogra_ibook> :)
[09:36] <siretart> yay for crimsun! :)
[09:36] <dholbach> and see how well we do
[09:36] <sistpoty> yay for crimsun from /me as well
[09:36] <sistpoty> probably ajmitch for nightly changes?
[09:37] <lucas> yeah, I was about to say that TZ problems should be considered
[09:37] <\sh> but I wouldn't count on that
[09:37] <ogra_ibook> how many did we have in breezy ? 3 ? 5 ?
[09:37] <siretart> ogra_ibook: too few
[09:37] <\sh> ogra_ibook: 4 or 5 ... you dholbach siretart I and ?
[09:37] <ogra_ibook> lucas, you can cover TZ shifts on the ML :)
[09:38] <ogra_ibook> i think ajmitch too
[09:38] <lucas> true
[09:38] <ogra_ibook> and crimsun
[09:38] <siretart> ok, so I count 4 + 2 proxies, which need approval by TB, yes?
[09:38] <ogra_ibook> so we were at least 5 
[09:38] <dholbach> we need elmo to sync (or maybe to do approvals), let's raise the issue at the TB
[09:38] <dholbach> we can still decide  then
[09:39] <ogra_ibook> yuo
[09:39] <siretart> ok
[09:39] <ogra_ibook> err yup
[09:39] <sistpoty> next item?
[09:39] <ogra_ibook> elmo also need the list ...
[09:39] <lucas> ok, packages that FTBFS (fail to build from source)
[09:39] <lucas> who will do the mass testing ? how ? (pbuilder ?)
[09:39] <\sh> upcoming todos
[09:39] <sistpoty> lucas: not so fast...
[09:39] <lucas> ah
[09:39] <lucas> sorry
[09:39] <lucas> missed 2 items :-)
[09:40] <dholbach> lucas: test rebuild on the buildds?
[09:40] <lucas> the buildd don't pbuild
[09:40] <dholbach> we can infinity to do this
[09:40] <\sh> so....bug fixing, unmet deps are the most common workloads these days after uvf 
[09:40] <dholbach> they sbuild, yes
[09:40] <sistpoty> ok, well I named the point "upcoming todo's" to try to list what should be our next priorities after uvf
[09:40] <siretart> dholbach: yes, we should ask lamont for that. but earlier than for breezy!
[09:40] <dholbach> siretart: absolutely, of infinity rather
[09:40] <elmo> eh?
[09:40] <\sh> ftbfs issues we can sort out with infinity/lamont and their "testbuilds of the universe"
[09:40] <elmo> what are you guys talking about WRT me?
[09:41] <ogra_ibook> elmo, uvf exception handling
[09:41] <ogra_ibook> elmo, and who is your MOTU contact to approve stuff
[09:41] <siretart> elmo: we agreed on proxies who are allowed to request syncs after UVF && FF from you
[09:42] <elmo> oh, ok, fine
[09:42] <LaserJock> I hate to be a pain but I gotta leave in 3 min. is there anything needing I or MOTUScience team? 
[09:42] <sistpoty> LaserJock: from the agenda, nothing science-specific
[09:42] <sistpoty> LaserJock: for the rest you can read the irc-logs or the minutes (once they are there)
[09:43] <LaserJock> I just wondered about the LP team item
[09:43] <sistpoty> ok, back to "what's priorities after uvf"
[09:43] <ogra_ibook> bugs
[09:43] <sistpoty> I guess one of the big priorities should also be reviewing packages... then we have unmet deps and bugs
[09:43] <dholbach> new packages
[09:44] <dholbach> yeah
[09:44] <ogra_ibook> as its for main 
[09:44] <dholbach> i'll do the apt-get.org import as well :/
[09:44] <dholbach> but bugs, of course
[09:44] <dholbach> the more the better
[09:44] <dholbach> we have a *bunch* piled up on launchpad
[09:44] <sistpoty> ok, for unmet deps, ajmitch wanted to write some stuff iirc... hopefully we'll have some webtool for it as well
[09:45] <raphink> hehe
[09:45] <siretart> sistpoty: I have this: http://tiber.tauware.de/~siretart/unmet/
[09:45] <sistpoty> ah, yes, I forgot ;)
[09:45] <lucas> which kind of deps ? build-deps ?
[09:45] <siretart> lucas: no, binary dependencies
[09:46] <\sh> ok...can we agree on "prio 1) bugs, prio 2) unmet deps prio 3) poke buildd when it's necessary to rebuild universe?"
[09:46] <siretart> lucas: basically the output of apt-cache -i unmet
[09:46] <sistpoty> \sh: and 4) reviewing new packages
[09:46] <\sh> sistpoty: ok..that whould be 1b)
[09:46] <\sh> not 4
[09:46] <siretart> \sh: 3 does not necessarily block human ressources. I think it should be started quite quickly
[09:47] <raphink> hehe
[09:47] <sistpoty> siretart: you might want to talk to ajmitch, he said s.th. bout britney ;)
[09:47] <lucas> we could run piuparts on the whole universe
[09:47] <\sh> siretart: yepp...
[09:47] <dholbach> if we all concentrate on a review day, we can achieve quite much
[09:47] <lucas> this would catch them all
[09:47] <sistpoty> lucas: catch what?
[09:47] <raphink> yep I think so
[09:47] <lucas> missing deps
[09:47] <raphink> if we do better than last time ;)
[09:48] <lucas> packages that don't install etc
[09:48] <sistpoty> we might do many things, if s.o. volunteers ;)
[09:49] <raphink> :)
[09:49] <sistpoty> ok, next item?
[09:49] <lucas> maybe there are some plans for this on the ubuntu scale
[09:49] <lucas> not MOTU
[09:49] <lucas> we should ask in TB
[09:49] <sistpoty> oh, sorry, I forgot another important point that falls under "TODO"
[09:49] <\sh> lucas: what plans?
[09:49] <lucas> plans for pbuilder builds + piuparts runs
[09:50] <dholbach> sistpoty: fire away
[09:50] <sistpoty> point is: soyuz...
[09:50] <\sh> lucas: hmmm..if, then it will be soyuz :) and buildd integration in launchpad :)
[09:50] <sistpoty> will it come, when, what will change, are we going to die?
[09:50] <lucas> \sh: I'm talking about dapper
[09:51] <\sh> sistpoty: dapper +1 :) 
[09:51] <lucas> not dapper+x ;)
[09:51] <\sh> lucas: I don't think infinity will deal now with pbuilder :) 
[09:51] <lucas> I'll take care of the issue with infinity and the TB
[09:51] <sistpoty> \sh: ah, good to know... thought I heard some rumors of soyuz being available very next days :)
[09:51] <siretart> sistpoty: we are definitly going to die, except the immortals ;) - but hopefully not related to ubuntu work 
[09:51] <sistpoty> hehe
[09:51] <lucas> I'm interested in providing CPU power too anyway
[09:52] <ogra_ibook> lucas, for unmet deps, get familiar with germinate ...
[09:52] <\sh> sistpoty: well...it could be as well a release cycle like "hurd" :)
[09:52] <lucas> piuparts catches much more than germinate
[09:52] <sistpoty> \sh: or longwait?
[09:52] <raphink> \sh: you mean 1.0 is released in 20 years ?
[09:53] <\sh> ASK #launchpad :)
[09:53] <sistpoty> ok, I guess we're getting offtopic... let's move on to next point?
[09:53] <dholbach> :)
[09:53] <raphink> sistpoty: yep
[09:53] <siretart> MOTU Team Reorg?
[09:53] <\sh> ok..lp motu teams reorg
[09:53] <sistpoty> lucas: your stage ;)
[09:53] <lucas> There is currently a high number of MOTU-related teams on Launchpad. I proposed a new organization on https://wiki.ubuntu.com/MOTUMeetingTeamReorg which (I think) makes it easier to understand and use. Please read the wikipage and comment.
[09:54] <\sh> ah well..
[09:55] <\sh> the blue teams: members of the blue teams don't need to be members of MOTU
[09:55] <\sh> everyone is normally allowed to enter :)
[09:55] <lucas> there are no members of MOTU
[09:55] <\sh> actually for MOTUIM :)
[09:55] <lucas> except the owner + teams
[09:55] <raphink> lucas : then the "normal" MOTUs are in Ubuntu-dev only?
[09:55] <lucas> yes
[09:55] <\sh> no
[09:56] <\sh> ubuntu-dev means only people with universe upload rights
[09:56] <raphink> \sh: according to the scheme I mean
[09:56] <lucas> \sh: elaborate
[09:56] <lucas> ok, so some people with universe upload rights are not MOTUs ?
[09:56] <lucas> (that was my question on the list)
[09:56] <\sh> lucas: yes
[09:57] <\sh> lucas: every core dev has universe upload rights, but is not always a MOTU, neither interested in MOTU
[09:57] <raphink> you have to be a dev to be a MOTU
[09:57] <raphink> but being a dev doesn't make you a MOTU
[09:57] <\sh> raphink: no..
[09:57] <lucas> ok
[09:57] <raphink> right?
[09:57] <raphink> ...
[09:57] <lucas> \sh: who are MOTUs then ?
[09:57] <\sh> ubuntu-dev means only "universe upload rights"...
[09:57] <raphink> yes
[09:58] <ogra_ibook> ubuntu-core-dev is a member of ubuntu-dev 
[09:58] <raphink> and I mean MOTUs are necessarily ubuntu-dev 
[09:58] <raphink> s
[09:58] <ogra_ibook> ubuntu-dev includes all MOTUs
[09:58] <\sh> lucas: MOTUs is a bunch of people who wants to work on the universe repos and/or working on the distro as volunteer...they can go further with universe uploads rights, but they don't have to
[09:58] <raphink> so among ubuntu-dev you have MOTUs, ubuntu-core-dev and others
[09:58] <ogra_ibook> \sh, nope
[09:58] <ogra_ibook> \sh, a MOTU is approved to upload
[09:59] <\sh> ogra_ibook: no :) MOTUs includes all ubuntu-devs...but MOTUs are more ( regarding the team lists)
[09:59] <raphink> hmm
[09:59] <ogra_ibook> \sh, i was there when we wrote the definition
[09:59] <raphink> do MOTUs belong to ubuntu-dev or ubuntu-dev belong to MOTUs ? ;)
[09:59] <ogra_ibook> \sh, MOTUs are all memebers of ubuntu-dev
[09:59] <\sh> ogra_ibook: in my POV MOTUs are Hopefuls + ubuntu-devs (reading the team names)
[09:59] <raphink> sistpoty: same here
[09:59] <\sh> ogra_ibook: not when I see the LP team list
[10:00] <ogra_ibook> \sh, nope, there are MOTUs and there are MOTU hopefuls
[10:00] <ogra_ibook> its ever been like this 
[10:00] <raphink> adjime
[10:01] <siretart> ogra_ibook: whats the difference between the lp group MOTU and ubuntu-dev? can't we merge them?
[10:01] <lucas> ok, so how do we transpose this to LP teams ? :-)
[10:01] <ogra_ibook> and there is a definition somewhere in the wiki
[10:01] <ogra_ibook> ...from the mataro conference
[10:01] <siretart> it causes much confusion
[10:01] <\sh> ogra_ibook: sorry...I was mistaken...what the lp teams are
[10:01] <ogra_ibook> siretart, yes, we should
[10:01] <sistpoty> siretart++
[10:01] <ogra_ibook> siretart, mdz didnt know about the exiatance of the MOTU launchpad group
[10:01] <raphink> confusing
[10:02] <lucas> ogra_ibook: can you comment on the proposed scheme on https://wiki.ubuntu.com/MOTUMeetingTeamReorg ?
[10:02] <ogra_ibook> so he created ubuntu-dev, which is the official MOTU team now
[10:02] <lucas> I used the MOTU as a way to join MOTU Hopefuls and ubuntu-dev
[10:03] <siretart> ogra_ibook: ubuntu-dev is used for upload permissions, MOTU is used for bug triage/management atm
[10:03] <ogra_ibook> siretart, hmm, we should probably keep them distinct
[10:03] <\sh> ogra_ibook: and we left the MOTU team because of the -bug mail address right?
[10:03] <ogra_ibook> yup
[10:04] <sistpoty> lucas: what is your rationale/use case behind this proposal?
[10:04] <ogra_ibook> i doubt the TB would be happy if we used ubuntu-dev for bugs etc
[10:04] <siretart> right
[10:04] <siretart> because main developers won't probably care that much about bugs in universe, I assume
[10:04] <lucas> sistpoty: it seemed it matched what I understood from this complex stuff ;)
[10:05] <ogra_ibook> lucas, our policy for teams was always: everybody can join, it must be one MOTU and one point of contact in the team (they may be the same person) and teams organize themselves internally
[10:05] <sistpoty> what do you want to achieve with this proposal?
[10:06] <\sh> well..what we want to achieve? seeing a team which is there because of managing upload rights, and a more theoretical team named MOTU which can be the mother of all MOTU* teams :) in a more practical way
[10:06] <ogra_ibook> to me it looks like you want to restrict access to cretain teams ...
[10:06] <lucas> sistpoty: make things easier to understand from the user or potential MOTU Hopeful point of view
[10:06] <ogra_ibook> *certain
[10:07] <lucas> ogra_ibook: ? my proposal is not about teams like MOTUScience, MOTURuby, etc
[10:07] <sistpoty> lucas: I'm not quite sure if using lp team relations will be succesful in making things clearer 
[10:07] <ogra_ibook> Teams accepting direct members are in blue. All other teams have no direct members except owner/admins.
[10:07] <sistpoty> lucas: instead of e.g. a wiki-page with some drawings like yours
[10:07] <ogra_ibook> lucas^^^
[10:07] <lucas> ogra_ibook: yes, and ?
[10:08] <lucas> I never talked about team creation
[10:08] <ogra_ibook> why would you restrict reviewers or mergers ?
[10:09] <lucas> because we don't need them if everybody is in MOTU through inclusion relationships
[10:09] <ogra_ibook> i just wouldnt put up rules for mergers or reviewers ... 
[10:09] <\sh> lucas: and people who are not team members of any team?
[10:09] <janimo> so can MOTUxxxxx teams have not-yet-motu members on launchpad?
[10:09] <lucas> \sh: they are MOTU Hopefuls
[10:09] <siretart> I think lucas proposal reflects reality better than the current situation in launchpad
[10:09] <lucas> \sh: which is blue, too
[10:09] <ogra_ibook> yes, everybody is a merger or reviewer in motu, why are there teams ? 
[10:10] <\sh> lucas: well in the MOTU IM team I have someone, who is not even a motu hopeful, but wants to work on packages...
[10:10] <sistpoty> ogra_ibook: for bug-mails
[10:10] <ogra_ibook> sistpoty, hmm, confusing
[10:10] <sistpoty> ogra_ibook: and for grouping bugs... that were the primary reasons
[10:10] <lucas> ogra_ibook: because you can assign a bug to motureviewers to mark it as 'I think it's ready, review needed'
[10:10] <siretart> ogra_ibook: I think you have a point there. every ubuntu-dev should be a reviewer rather than every motu
[10:10] <\sh> ogra_ibook: to assign bugs towards those teams, that a mail is generated
[10:11] <sistpoty> ogra_ibook: so that you can search for all bugs assigned to motu-merges (e.g.)
[10:11] <lucas> \sh: no problem, he is part of the MOTU 'galaxy' too
[10:11] <\sh> lucas: if "MOTU galaxy" is the MOTU team , then no
[10:11] <lucas> MOTU IM is in blue, next to MOTU RUby ;)
[10:11] <\sh> lucas: if you see it separated from the team view in LP then yes
[10:11] <ogra_ibook> sistpoty, yes, i understand, i just find the need for a full team page confsing
[10:11] <lucas> \sh: I don't understand what you mean
[10:11] <ogra_ibook> but thats a LP limitation
[10:12] <sistpoty> unfortunately :(
[10:12] <lucas> \sh: with my proposal, MOTUIM is included in MOTU. So anybody in MOTUIM is also in MOTU
[10:13] <\sh> lucas: the LP view is quite different from the idea of MOTU galaxy :) everybody who is bringing in patches to universe etc. belongs to the "MOTU galaxy" but they are not shown up in the LP team view of MOTU :)
[10:13] <ogra_ibook> "What about universe maintainers not willing to do MOTU work ?" 
[10:13] <ogra_ibook> what does this mean ? 
[10:13] <siretart> lucas: with your proposal, every bug assigned to MOTUReviewers would be assigned to ubuntu-dev and ubuntu-core-dev, too
[10:13] <siretart> lucas: so we would bother to many ppl with bugs we don't want them to bother
[10:13] <lucas> ogra_ibook: ubuntu-dev members who don't do MOTU work
[10:13] <ogra_ibook> lucas \sh: with my proposal, MOTUIM is included in MOTU. So anybody in MOTUIM is also in MOTU
[10:14] <lucas> siretart: yup, what's exactly the point ogra just raised
[10:14] <\sh> lucas: so ubuntu core dev :)
[10:14] <ogra_ibook> ^^^that cant work
[10:14] <lucas> so maybe we need a 'MOTU Developers' team instead of ubuntu-dev
[10:14] <ogra_ibook> since MOTUIM can have non MOTU members
[10:14] <ogra_ibook> as every team can
[10:14] <lucas> or MOTUWithUploadRights team ;)
[10:14] <ogra_ibook> you would make them MOTU automatically
[10:14] <raphink> loooool
[10:15] <lucas> ogra_ibook: please read 'MOTU' on the diagram as 'MOTU galaxy'
[10:15] <lucas> if you prefer
[10:15] <ogra_ibook> no, please dont
[10:15] <\sh> okokokok
[10:15] <lucas> if we :
[10:15] <\sh> one moment...
[10:15] <lucas> s/ubuntu-dev/MOTU/
[10:15] <ogra_ibook> currently you refer to the LP team 
[10:15] <lucas> s/MOTU/MOTUGalaxy/
[10:15] <lucas> on a diagram
[10:15] <lucas> would it be ok ?
[10:15] <ogra_ibook> and this should only contain approved MOTUs
[10:16] <ogra_ibook> thats even more confusing ...
[10:16] <lucas> ok, so let's create a MOTU Galaxy team which includes all subteams
[10:16] <siretart> lucas: what do you gain from another team?
[10:16] <lucas> siretart: currently, there are members of all MOTU related teams
[10:16] <ogra_ibook> yes, thats what i'm asking as well here
[10:16] <lucas> some people are members of several teams
[10:16] <\sh> technical solutions can't solve social problems
[10:16] <lucas> which is useless, etc
[10:16] <lucas> there's a lot of redundancy
[10:16] <ogra_ibook> its just bringing up more confusion
[10:16] <sistpoty> \sh++
[10:16] <ogra_ibook> i'd keep the LP teams distinct ...
[10:17] <lucas> I'd just like a clean mapping of the reality to launchpad
[10:17] <raphink> I don't see a pb with redundancy in teams
[10:17] <\sh> so which view do you have: the social view of MOTU or the technical LP view of MOTU?
[10:17] <raphink> I'm subscribed to ML that send me the same bugs three times
[10:17] <raphink> and that's ok
[10:17] <raphink> redundancy in work or bugs or so can be a pb
[10:17] <siretart> what about breaking all inclusion relationsships in the MOTU Teams?
[10:17] <raphink> but in teams ... well I don't see the pb
[10:17] <lucas> MOTUIM is part of MOTU I think
[10:17] <lucas> that's wrong, then
[10:17] <lucas> so we do no relationships between LP teams ?
[10:17] <ogra_ibook> yes
[10:17] <\sh> lucas: no
[10:18] <ogra_ibook> MOTUIM is a team with at least one MOTU
[10:18] <ogra_ibook> but its not member of MOTU as whole team
[10:19] <lucas> ok, let's reject the item, and just say that our policy regarding LP is 'join as much teams you can' :-)
[10:19] <\sh> lucas: there is no relation between the MOTUIM team and the MOTU team .. the only connection to the MOTU team is me (and nafallo, slomo) but nothing else...it
[10:19] <ogra_ibook> lucas, it isnt
[10:19] <sistpoty> I guess the policy is come to #ubuntu-motu and talk to people... 
[10:19] <lucas> ah sorry
[10:20] <lucas> MOTURuby is member of MOTU
[10:20] <ogra_ibook> lucas, join the teams you like to work with is and was the policy
[10:20] <lucas> not MOTUIM
[10:20] <ogra_ibook> nope
[10:20] <ogra_ibook> it cant
[10:20] <lucas> why is MOTURuby member of MOTU, and not MOTUIM ?
[10:20] <lucas> it is.
[10:20] <lucas> https://launchpad.net/people/motu
[10:20] <\sh> lucas: I'm in the ubuntu-dev team, because of the upload rights, I'm in the MOTU team, because I'm a MOTU and I'm team lead of MOTU IM...oh yes and the Kubuntu team 
[10:21] <lucas> ok, so let's remove inclusion relationships between team
[10:21] <lucas> s
[10:21] <siretart> any objections?
[10:21] <siretart> It seems to reduce confusion
[10:21] <sistpoty> no objections... let's move to the next item
[10:21] <ogra_ibook> hmm who added the teams there ? 
[10:21] <janimo> maybe MOTU should be just the groups of people doing regular merges, transitions etc
[10:21] <raphink> yeah next item :)
[10:21] <siretart> ogra_ibook: confused ppl (like probably me)
[10:22] <janimo> while the MOTUxxx groups usually care about one singel area and set of pacvkages
[10:22] <lucas> that's me again
[10:22] <\sh> not me
[10:22] <lucas> next or not next ?
[10:22] <sistpoty> go on
[10:22] <lucas> We currently accept a lot of packages through REVU. After they are uploaded, the maintainer is free to totally forget about it and leave us maintain them. I'd like to raise two issues :
[10:22] <lucas>  * Maybe we should find a way (writing a policy ?) to actually make REVU uploaders feel more responsible of what they upload in the long term.
[10:22] <lucas>  * Maybe we should consider removing some of the 300+ universe packages that are not in Debian. What's the procedure for this ? (note that popcon.u.c is broken, so we can't determine which packages are actually used).
[10:23] <ogra_ibook> siretart, heh
[10:23] <\sh> lucas: why? 
[10:23] <lucas> \sh: why what ?
[10:23] <\sh> lucas: ubuntu decided in the beginning not to have this maintainer thingy
[10:23] <lucas> ok, but who cares about the packages ?
[10:23] <lucas> I know we are not doing security updates for universe
[10:23] <siretart> lucas: everyone and nobody, thats how universe works
[10:23] <\sh> lucas: so actually I don't mind to touch packages which are not directly mine...but because they're in universe they're mine and yours and dholbachs and siretarts somehow
[10:24] <ogra_ibook> lucas, they disappear if nobody cares for them 
[10:24] <lucas> but every ubuntu user adding universe potentially get lots of root holes ;)
[10:24] <ogra_ibook> thats normal evolution :)
[10:24] <raphink> and if there is a new version in Deiban, it'll overwrite the package in universe anyway, which is likely to be for many of them since DDs are much more numerous
[10:25] <lucas> also, since we don't check if packages still work, there might be a lot of broken packages in universe
[10:25] <sistpoty> apart from that most of the ppl. of revu hang around in -motu or can be reached by mail... so it's easy to do a "nmu": just ask
[10:25] <siretart> ogra_ibook: uuh, I think the 'dissapear' part is worth another point on the agenda
[10:25] <ogra_ibook> siretart, why ? thats what happens ... 
[10:25] <lucas> sistpoty: I'm not concerned about packages which are actually used by a lot of users
[10:25] <lucas> I'm concerned about the invisible ones
[10:25] <\sh> siretart: if they disappear from debian, they disappear from ubuntu at some very special time...
[10:26] <lucas> potentially broken, or with security issues
[10:26] <ogra_ibook> siretart, if nobody cares for them, they'll not survive a transition etc
[10:26] <\sh> lucas: e.g.?
[10:26] <lucas> no idea, because nobody here obviously know about them ;)
[10:26] <lucas> ok, example: xnetcardconfig, a ruby packagez
[10:26] <siretart> ogra_ibook: how many package actually got removed that way yet?
[10:26] <lucas> not in debian
[10:26] <lucas> uploaded once, never updated
[10:26] <lucas> some users might have install it
[10:27] <lucas> it might be rootable
[10:27] <ogra_ibook> siretart, none, because we cared for most of them :)
[10:27] <siretart> ogra_ibook: what about packages which got removed in debian but are still in ubuntu?
[10:27] <\sh> lucas: hmmm...sure...there is a ruby team..and this team can decide if ubuntu needs this package or not
[10:27] <ogra_ibook> siretart, if someone wants to care for them :)
[10:27] <sistpoty> basically I dislike the idea of removing packages, just because nobody uses them
[10:27] <lucas> ok
[10:27] <siretart> I think we should work on a process for package removals
[10:27] <lucas> problem is, I'm not using it
[10:27] <lucas> but I don't know if somebody else is
[10:27] <lucas> how can I know ?
[10:28] <siretart> ogra_ibook: how to you know when 'nowbody cares anymore for a package'?
[10:28] <raphink> I used to use xnetcardconfig lucas 
[10:28] <\sh> lucas: I'm not using actually 95% of universe but should I propose to elmo to remove 95% of universe?
[10:28] <raphink> once
[10:28] <lucas> it was just an example
[10:28] <lucas> \sh: that's exactly the problem
[10:28] <\sh> lucas: but I do care about my universe work..and therefore I have to touch those packages, so I do care :)
[10:29] <sistpoty> if nobody uses these/nobody has these installed, it's not a probrem if a packages has issues. if ppl. have it installed, it's likely that they'll report bugs
[10:29] <\sh> even if i'm not using it in my daily work
[10:29] <sistpoty> or even start caring for the package
[10:29] <raphink> how many packages do we even merge that we won't ever use
[10:29] <raphink> ;)
[10:29] <ogra_ibook> siretart, if it lies broken on the floor in front of me and nobody complains ;)
[10:29] <lucas> sistpoty: not likely. not many people report bugs
[10:29] <\sh> raphink: a lot :)
[10:29] <lucas> syncs/merges are different, since debian maintains them
[10:29] <raphink> \sh: yes ;)
[10:29] <sistpoty> and maybe some people use even the source (sourcepackage)
[10:30] <siretart> ogra_ibook: cool. that would apply to mythtv!
[10:30] <lucas> ogra_ibook: what about blog entries like 'ubuntu is crap, I installed this and it doesn't work at all!'
[10:30] <\sh> lucas: hmmm...nope...many packages are not compatible with debian anymore....gajim is a good example...and I know why :)
[10:30] <ogra_ibook> siretart, drop it then :) (but also deal with mdz afterwards ;) )
[10:31] <siretart> ogra_ibook: he orphaned it and asked for an adopter
[10:31] <ogra_ibook> lucas, look for a comment section and add a link to malone ;)
[10:31] <\sh> lucas: well...we have settled communication channels like malone for bugs...we can't read all blog pages about "this and that is not working". there was one colleague of mine, who tried to do it, and forced us to read forum posts...well...he's gone now :)
[10:31] <ogra_ibook> siretart, oh, he probably bought a TV now :)
[10:31] <\sh> lucas: it doesn't work 
[10:31] <ogra_ibook> who knows
[10:32] <lucas> poll: do you prefer: (A) get as many packages in, even if we can't make sure all of them work as expected. (B) maintain a smaller amount of packages, but be reasonably sure they work.
[10:32] <raphink> a
[10:32] <\sh> lucas: how do you determine the need of (B)?
[10:33] <siretart> lucas: a is how universe is constructed and expected to work
[10:33] <\sh> lucas: and don't mention popcon
[10:33] <lucas> \sh: by using popcon would be great
[10:33] <\sh> lucas: no
[10:33] <raphink> we want A
[10:33] <raphink> A provides bugs
[10:33] <raphink> and bugs make software better
[10:33] <sistpoty> vote, \sh! ;)
[10:33] <raphink> )
[10:33] <raphink> :)
[10:33] <lucas> raphink: you won't know anything about those bugs
[10:33] <raphink> lucas: if they are reported, we will
[10:33] <ogra_ibook> lucas, i agree with sabdfl on a ...
[10:33] <ogra_ibook> its a declared target 
[10:33] <doko_> sistpoty, dholbach, lucas, siretart: just updated the libstdc++ list, the allocator list is currently updating, no need to rebuild, they were all tried and failed. just fix ;)
[10:33] <lucas> since joe doesn't know about bug reports and will only blog that ubuntu sucks
[10:34] <crimsun> doko_: thanks
[10:34] <\sh> software comes and goes....like the dinos
[10:34] <siretart> doko_: thanks!
[10:34] <dholbach> doko_: rocking, thanks.
[10:34] <raphink> I consider open-source users to be generally a bit more responsible about reporting bugs than proprietary soft ones
[10:34] <sistpoty> doko_: are they rebuilt on a daily basis?
[10:34] <sistpoty> (the lists)
[10:34] <sistpoty> and thanks doko_ btw ;)
[10:34] <\sh> doko_: merci :)
[10:35] <raphink> thanks doko_ 
[10:35] <lucas> \sh: what's the problem with popcon ?
[10:35] <\sh> lucas: it's off by default I think
[10:36] <sistpoty> ok, since ogra_ibook had the ultimate vote (sabdfl's), what about considering a) the agreement and move to the next topic?
[10:36] <lucas> http://popcon.ubuntu.com never get refreshed
[10:36] <lucas> just a note
[10:36] <\sh> lucas: and if it wouldn't be switched of by default, I would blog about breaking my private environment of ubuntu
[10:36] <doko_> sistpoty: no, takes too long, I'll rebuild these on request
[10:36] <lucas> does MOTURuby has the right to request removal of a ruby-related package ?
[10:36] <sistpoty> ok, thx doko_: 
[10:36] <\sh> sistpoty: there is no vote, because there is no mathematical solution for b)
[10:36] <ogra_ibook> sistpoty, this came up at hoary time when we discussed apt-get.org inclusion
[10:37] <lucas> if MOTURuby doesn't want to hear people saying that ruby sucks in dapper ?
[10:37] <sistpoty> but can we agree to move to the next topic (at least :P)?
[10:37] <crimsun> lucas: as opposed to fixing it?
[10:37] <lucas> crimsun: yes
[10:37] <lucas> because it's not integrated in debian, and nobody seems to care
[10:38] <crimsun> it's going to have to be fixed _somewhere_, but yes, let's move on
[10:38] <\sh> lucas: welcome to the world of volunteers :) 
[10:38] <raphink> :)
[10:38] <sistpoty> ok, next item: Collaborative maintenance on tiber via svn or other means
[10:38] <sistpoty> who listed this? siretart?
[10:38] <raphink> there are always people to criticize volunteer and not do anything to help ;)
[10:38] <\sh> I'm publishing my bzr archives on tiber in my public_html dir :) 
[10:39] <lucas> but there's no bzr-buildpackage
[10:39] <siretart> sistpoty: yes, that was me
[10:39] <lucas> also, collaborative maintenance != bzr model ;)
[10:39] <\sh> lucas: so? I can use bzr and be able to export :) and use debuild and pbuilder...
[10:39] <sistpoty> siretart: grab the mic ;)
[10:39] <siretart> this touches a bit the previous point
[10:39] <raphink> is that link to buxy's proposal?
[10:39] <siretart> yes, sort of
[10:39] <ogra_ibook> i do all my development in bzr (public available on p.u.c) as all main devs do 
[10:40] <raphink> s/link/linked/
[10:40] <siretart> buxy's proposal was to have a common svn repo, where interested ppl can just commit
[10:40] <lucas> ogra_ibook: using bzr is a PITA when you don't have an account on tiber or somewhere else
[10:40] <ogra_ibook> since launchpad will offer access to packages in bzr as well, i think you need to khave a working gateway layer to svn for this proposal
[10:40] <siretart> we have quite some packages, which are activley maintained by us MOTUs and have no debian upstream
[10:41] <ogra_ibook> lucas, that will change with the supermirror
[10:41] <siretart> since we are doing team maintenance, I think it is reasonable to have a common repository for them
[10:41] <lucas> ogra_ibook: ETA ?
[10:41] <\sh> lucas: why? some webspace is enough..and it can be anywhere..if someone wants that I merge his branch, he should give me the location.
[10:41] <ogra_ibook> lucas, no idea
[10:41] <ogra_ibook> but soon i guess
[10:41] <dholbach> i have a visitor here, i will leave now - but i'll read the irclog from now on.
[10:41] <\sh> when hct is deployed
[10:41] <dholbach> have a nice evening.
[10:41] <siretart> I don't consider bzr suitable for group package maintenance yet, so I'd propose svn
[10:41] <sistpoty> bye dholbach
[10:41] <ogra_ibook> dholbach, have fun
[10:41] <siretart> bye dholbach 
[10:41] <dholbach> thanks a lot
[10:42] <raphink> bye dholbach 
[10:42] <siretart> we could host that repo on tiber and grant individuals svn access. this is basically buxys proposal for debian, right
[10:42] <raphink> mhm
[10:43] <lucas> yeah, why not do that on alioth ?
[10:43] <siretart> my question is: does anyone have objections about this? - and should the different MOTU Teams have different repos or should everything go into ONE big archive?
[10:43] <lucas> it would benefit more people
[10:43] <sistpoty> siretart: what packages do you think of? all that became uploaded from revu? or just a subset of ppl. willing to do comaintenance?
[10:43] <\sh> siretart: I thought buxys proposal was "collaborative work between ubuntu and debian or vice versa"...which means, debian is going away from maintainership
[10:43] <siretart> lucas: because we are ubuntu and cannot occupy debians ressources for ubuntu development
[10:43] <crimsun> siretart: would be best to stick to one big one
[10:43] <ogra_ibook> lucas, because we have LP ?
[10:43] <lucas> siretart: buxy proposed we do
[10:44] <siretart> \sh: I didn't get buxy's proposal that way
[10:44] <raphink> ogra_ibook: many DDs will refuse to work with LP :(
[10:44] <lucas> \sh: buxy doesn't have the power to propose this ;)
[10:44] <siretart> lucas: he is an alioth admin, why not?
[10:44] <raphink> lucas: buxy has quite some power ;)
[10:44] <lucas> siretart: I was talking about moving away from maintainership
[10:45] <raphink> being one of the 3 or 4 alioth admins
[10:45] <sistpoty> siretart: I'm already having a package on alioth (min12xxw) to test the collaborative maintenance
[10:45] <siretart> lucas: oh, your right, sorry
[10:45] <\sh> lucas: that's what I mean, how can they "pray" for a collaborative work, when they don't have such a system. svn doesn't mean, everyone is allowed to branch and merge and commit to one package at all
[10:45] <ogra_ibook> raphink, LP will be the core of ubuntu development 
[10:45] <siretart> sistpoty: If I find some time, I will apply, too
[10:45] <raphink> yes ogra_ibook, so it's fine for us ubuntu devs and contributors
[10:45] <sistpoty> but I don't know how many ppl. from debian side are caring for that alioth-project... if we come with 20 devs it might be overkill for alioth
[10:45] <lucas> we could start on alioth using the collab-maint project, and move to LP when LP is ready (for dapper+1 or +2)
[10:45] <sistpoty> (at least now)
[10:46] <ogra_ibook> i dont discuss debian development here ... and i thought the topic is collaboration, not forc one or the other to use the others tools ;)
[10:46] <siretart> ogra_ibook: you're right. I proposed using tiber, not alioth
[10:46] <raphink> and I tend to agree
[10:46] <lucas> siretart: how will you handle security ?
[10:47] <siretart> ogra_ibook: some packages could be maintained on alioth, that would be more or less 'upstream work'
[10:47] <ogra_ibook> siretart, thats fine 
[10:47] <siretart> lucas: security in what way?
[10:47] <lucas> if you give svn access to lots of people
[10:47] <sistpoty> yes, basically I agree, siretart. we might have public read access and probably some few persons who can be naibed (bringing packages to utnubu/alioth)
[10:47] <siretart> lucas: what do you want to protect from whom?
[10:47] <ogra_ibook> i think its fine for the debian side to use alioth though
[10:47] <\sh> regarding MOTUIM, I'm going to do the work with bzr...so gajim is bzr conform..xterm is bzr conform...and everybody who wants to branch, can branch, and if someone is giving me a pointer to a bzr archive and tells me, my patch is quite nice, I'll consider merging it, and daniels can take it over again, when ever he wants...and debian can use those archives as well...
[10:48] <\sh> and nafallo is doing bzr as well :)
[10:48] <siretart> \sh: do you have a list where can I branch what of 'your' packages?
[10:48] <lucas> siretart: guys who get their system rooted, got no passphrase, and therefore give access to tiber from the outside
[10:48] <ogra_ibook> lucas, thats why i prefer one controlled bzr archive ...
[10:48] <siretart> lucas: I don't intend to give out shell access at all
[10:49] <\sh> siretart: http://revu.tauware.de/~shermann/packages/ and you find all patch branches in separate branches :) take what you need :)
[10:49] <lucas> ogra_ibook: svn-{inject,buildpackage} really rocks for collaborative maintenance compared to bzr
[10:49] <\sh> siretart: the description of the directories is straight forward, if you are conform with the upstream development
[10:49] <sistpoty> \sh: didn't you want to focus a bit on programming? what about bzr-buildpackage ;)
[10:50] <\sh> sistpoty: it's called hct :) and keybuk is working on it :)
[10:50] <raphink> :)
[10:50] <sistpoty> but it's not ready yet :P
[10:50] <\sh> sistpoty: well...until then I'm doing it the manual way
[10:51] <lucas> siretart: have you contacted buxy about his proposal ?
[10:51] <lucas> (also about REVU2)
[10:51] <siretart> lucas: what do you mean exactly?
[10:51] <sistpoty> back to topic again, I basically like the idea of having packages around at one central place, or at least one central place to know what packages reside where
[10:51] <siretart> lucas: I joined the discussion on the mailing list
[10:51] <lucas> well, maybe his opinion could be interesting
[10:52] <raphink> buxy is on #ubuntu-motu currently
[10:52] <raphink> ;)
[10:52] <lucas> just a poll: we should use (A) svn on tiber or alioth, to be determined (B) bzr
[10:52] <raphink> maybe he could jump in and give us his opinion
[10:53] <sistpoty> erm... what about another suggestion: everybody to his likes
[10:53] <\sh> sistpoty: to be honest, my central place to work with packages is archive.ubuntu.com/ubuntu and a deb-src line in my sources.list...which means, all patches are inside the packages, or in the .diff.gz which I can read and understand :)
[10:53] <lucas> sistpoty: what would you use ?
[10:53] <lucas> it's a poll, not a vote
[10:53] <siretart> \sh: the point is to give svn access to ppl which are not in the ubuntu keyring (yet)
[10:53] <sistpoty> I'd prefer a), but if there is a package with b) there, I'd use b)
[10:53] <ogra_ibook> lucas, you dont understand ... 
[10:54] <\sh> siretart: the keyring has nothing to do with "populating changes towards packages".
[10:54] <ogra_ibook> there will be a central mirror for ubuntu packages in bzr format in the future, so you need to use bzr
[10:54] <sistpoty> \sh: and I also wrote that I'd like at least a list, where I can get to bzr or svn packages
[10:54] <siretart> \sh: the same point is raised by buxy, btw. he wants to give ppl with no strong commitment to packages the chance to contribute to a collaborative development
[10:54] <ogra_ibook> or a layer that imports it in your preferred system
[10:55] <siretart> \sh: svn commit is way faster than filing patches via malone
[10:55] <sistpoty> maybe we could provide svn on tiber, and have a wiki-page that states if a package is in svn or if it's in bzr and where to get it
[10:55] <\sh> siretart: but this is contrary to the debian philosophy, and I see his proposal more in this way of a collaborative work between MOTUs and debian maintainers.
[10:56] <sistpoty> hi buxy
[10:56] <raphink> hi buxy 
[10:56] <siretart> \sh: I don't think buxy proposale about collaborative maintenance was 'just' about collaboration between ubuntu and debian
[10:56] <\sh> siretart: patches are small and if someone has to provide something, he can file a bug. or he is involved directly in #ubuntu-motu :)
[10:56] <siretart> huhu buxy 
[10:56] <siretart> \sh: I want to reduce overhead.
[10:57] <\sh> siretart: and can send me a debdiff, bzr archive url, svn access, or what ever, if he's not a member of ubuntu-dev :)
[10:57] <buxy> hi everyone, I'm sorry to join so late in the discussion but I've just been invited by sirestart and raphink :)
[10:57] <raphink> ;)
[10:57] <raphink> buxy: well I guess you're still the best guy to talk about your proposal and make it cleare
[10:58] <raphink> s/cleare/clearer/
[10:58] <buxy> Ok, if you think it's needed I can try explain the context
[10:59] <siretart> buxy: from this discussion here, I'm a bit confused. Did you really invite all MOTUs to commit and work on packages for ubuntu (and debian as well this way) in the collab-maint svn repo?
[11:00] <\sh> following the last discussion at the Debian-QA meeting on Darmstadt, it
[11:00] <\sh> appears that the proposal called "Collaborative maintenance" is of generic
[11:00] <\sh> interest :
[11:00] <\sh> - for Debian sponsors and Debian mentors
[11:00] <\sh> - for QA which may use the infrastructure for orphaned packages
[11:00] <\sh> - for Ubuntu's MOTU School
[11:00] <\sh> this is the first paragraph of the mail :)
[11:01] <buxy> siretart: it's a possibility that I offered yes, but as I told, the important part is what's above "svn" and we could make the infrastructure support more than just svn
[11:01] <raphink> and I've actually been wondering what was meant by "MOTU School" 
[11:02] <siretart> buxy: yes. I see. 
[11:02] <\sh> raphink: he means MOTU motu school is something different..but quite popular :) 
[11:02] <buxy> raphink: The MOTU school is the "mentoring process inside Ubuntu" for me :)
[11:02] <raphink> oh ok ;)
[11:03] <sistpoty> oh, he, no... it's irc lessons about a specific topic
[11:03] <raphink> buxy: MOTU school is something else for us but ok :)
[11:03] <raphink> at least I get it :)
[11:03] <ogra_ibook> buxy, #ubuntu-motu is the mentoring process we use ;)
[11:03] <lucas> buxy: you mean REVU actually
[11:03] <lucas> (basically)
[11:04] <buxy> \sh: yes the context is summed up in the wiki page, the project started for managing orphaned packages but we found out that it could be a good way to handle packages from new maintainers and in general for packages maintained by contributors outside of Debian (and MOTU are contributors outside of Debian for me)
[11:05] <buxy> "contributors outside of Debian" is badly said, I should have said "non-DD contributors"
[11:05] <\sh> buxy: so does it mean, debian will go away from the maintainership of packages and let everybody who wants touch packages? without being killed or flamed of the former maintainer?
[11:06] <lucas> \sh: the proposal is about *some* packages, not all packages.
[11:06] <\sh> lucas: even orphaned packages are still maintained..the former maintainer will help the new maintainer to take over the package..
[11:06] <buxy> \sh: this can't be a one-day change, but maintainers who are willing to go in that direction could put their packages in a pool where many people could work on it
[11:06] <\sh> lucas: (in the best situation)
[11:07] <buxy> \sh: but not all packages will be managed that way
[11:09] <siretart> buxy: does the debian QA team has a 'common' svn repo for orphaned packages?
[11:09] <\sh> buxy: so it can be possible to branch this package source and provide an archive url towards the package maintainer...if I want to work on this particular package...
[11:09] <\sh> buxy: despite the fact of a centralized package repository
[11:09] <buxy> siretart: not yet, but QA people have nothing against that
[11:10] <\sh> buxy: because this is my meaning of collaboration...if I want to contribute, the maintainer of package is always the last point of decision if he wants my patch or not
[11:10] <siretart> buxy: currently, the utnubu team has its own 'common' svn repo. are they expected to keep their own repo or merge it with the collab-maint one?
[11:10] <\sh> means: there is no need of something centralized..
[11:11] <buxy> siretart: that's a topic that I haven't brought up yet, but of course I'd like to push in that direction
[11:12] <tseng> eh
[11:12] <\sh> moins tseng 
[11:12] <buxy> \sh: collaboration is not only a tool, it's a behaviour
[11:12] <buxy> \sh: if you work n a branch on your side, and tell the maintainer what you did and where he can get the stuff to get integrated, that's fine
[11:13] <\sh> buxy: yes...and a nice one...but again...the maintainer is the last resort of the decision
[11:13] <\sh> buxy: that's what I said, yes :)
[11:13] <sistpoty> ok, let's try to get back to the topic?
[11:13] <siretart> yes, please
[11:14] <sistpoty> ok... what prosals are there/can we agree on s.th. or should we defer this?
[11:14] <siretart> buxy: the discussion was to instantiate a common svn repo for us motus
[11:15] <siretart> I proposed to host it on tiber, mainly because I did not want to abuse alioth for mainly ubuntu work
[11:15] <\sh> sistpoty: what proposal...if it's regarding buxy, we are speaking of something to be made between debian and ubuntu, if we are talking about "motu collaboration" we have actually
[11:15] <siretart> we want to maintain there package which we motu's activly maintain
[11:16] <siretart> so the question is: should this be rather on tiber or on alioth. buxy: what do you think?
[11:16] <ajmitch> for my packages, that is
[11:17] <\sh> if we want to maintain the packages for ubuntu, then we should discuss an ubuntu way...if we are talking about debian and ubuntu, we should postpone this discussion to a better time and with all people involved in this....] 
[11:18] <buxy> siretart: difficult to say, but hosting on alioth is ok for me as long as we agree that all packages which are not ubuntu-specific should also be integrated in Debian (even if the upload is in fact done by utnubu)
[11:18] <lucas> \sh: can you define "all people involved in this" ?
[11:18] <\sh> lucas: all debian responsibilities and as well all ubuntu reponsibilities. 
[11:19] <\sh> lucas: because this is nothing for the motu meeting at all..it touches more then "svn repos for motu on tiber"
[11:19] <ajmitch> lucas: it'd involve others from the utnubu team
[11:20] <siretart> buxy: I think mostly about packages which are interesting for debian, too, but I didn't care enough for searching for a sponsor, because I did not wanted to be the only maintainer. I think there are quite some packages of this kind
[11:21] <siretart> buxy: for packages which are only of interest for ubuntu, thats a clear matter
[11:21] <siretart> buxy: what is the procedure to get svn access to the collab maint svn?
[11:21] <buxy> siretart: okay, then I think alioth is a good choice
[11:22] <tseng> siretart: anyone can get an account on alioth
[11:22] <buxy> siretart: mail me and tell me your alioth login name and why I should add you to the project :)
[11:22] <tseng> siretart: team members can give you access to the svn
[11:22] <buxy> tseng: team admin only
[11:22] <ajmitch> buxy: can I join too? :)
[11:22] <buxy> ajmitch: sure :)
[11:22] <siretart> buxy: great. will do. (my login is siretart-guest ;)
[11:23] <ajmitch> I'll get over my dislike of svn one day
[11:23] <siretart> ok. I think we are done with this point
[11:23] <siretart> next?
[11:23] <sistpoty> siretart++
[11:23] <sistpoty> next point is "Brainstorming/Ideas how to organize divergence in our universe"
[11:23] <sistpoty> who's one was that?
[11:23] <ogra_ibook> "divergence in our universe" ??
[11:24] <siretart> lucas: I think http://tiber.tauware.de/~lucas/versions/unimultiverse.html is really rocking! I wanted to say you a big THANK YOU for that
[11:24] <sistpoty> ogra_ibook: copy'n'paste from wiki
[11:24] <siretart> ogra_ibook: I'm talking about divergence from our upstream: debian
[11:24] <lucas> :-) thank you for hosting me
[11:24] <lucas> and thank sistpoty for providing the merge comments :)
[11:24] <sistpoty> he, np
[11:25] <siretart> lucas: you have a coloum there for notes on individual packages which can be edited via the wiki
[11:25] <lucas> siretart: yes ?
[11:25] <\sh> siretart: when debian will adjust to our infrastructure, e.g. modular xorg etc. those diffs will automagically go away
[11:25] <siretart> I'd like that everyone who touches a package in ubuntu makes a note about what kind of divergence the package is in ubuntu. perhaps you remember my posting to the mailinglist
[11:26] <siretart> \sh: exactly thats my point
[11:26] <\sh> siretart: transitions...well, if they are announce earlier for debian then ubuntu, then we will have less packages to touch, if not..well you know the fun :)
[11:26] <ajmitch> \sh: xlibs-dev is removed from sid now - I think it's just the gl libs that are a hassle
[11:26] <siretart> \sh: I'd like to know when all patches e.g. because of xorg are obsolete
[11:26] <lucas> siretart: I started that for ruby packages, but not sure if there should be a 'MUST' here
[11:26] <ajmitch> siretart: that would require us to identify by patch that it's a build-depends change :)
[11:27] <ajmitch> siretart: it *could* be done with grep & a fair bit of work
[11:27] <sistpoty> I already feared, you would say that, ajmitch ;)
[11:27] <\sh> siretart: there was last time a blog post of the xorg maintainer, and he is pushing the modular xorg now into debian, so it can be, that for dapper+1 those changes are gone
[11:27] <ajmitch> sistpoty: why do you say that?
[11:27] <sistpoty> ajmitch: that it could be done automatically ;)
[11:28] <siretart> ajmitch: there are many types of divergence. I'd like to have some more overview and statistics about how far we are diverged from debian and why
[11:28] <ajmitch> sistpoty: nah, I didn't say automatically
[11:28] <\sh> siretart: means dapper+1 will be a fcking sync orgy
[11:28] <sistpoty> ajmitch: come on, you implied it :P
[11:28] <ajmitch> sistpoty: certainly, and we can identify a few of those automatically, to keep sistpoty happy :)
[11:28] <ajmitch> heh
[11:28] <sistpoty> hehe
[11:28] <siretart> \sh: that would be really awesome, because I think we have diverged from debian to much. and way too often unnecessarily
[11:29] <ajmitch> siretart: of course, and it's always a matter of what time we have to sort this out
[11:29] <sistpoty> siretart, lucas: where should we post/submit the divergence?
[11:29] <ajmitch> in between the bugfixing
[11:29] <\sh> siretart: well...patches like launchpad integration etc. which are not taken by debian upstream neither real upstream will stay in ubuntu, so we will always have an ubuntuX package
[11:29] <siretart> sistpoty: and now we come to the point I wanted to raise
[11:29] <lucas> sistpoty: http://wiki.ubuntu.com/MOTUNotes
[11:30] <ajmitch> siretart: not filing bugs, is it?
[11:30] <siretart> sistpoty: I think we have 2 options: http://wiki.ubuntu.com/MOTUNotes, or some more magic with postgresql and javascript.
[11:30] <siretart> ajmitch: would you really file a new bug for each diverged package explaining why it diverged? that would be true overkill
[11:30] <sistpoty> siretart: I don't like the 2nd option... we'd need some kind of user management for this to work
[11:30] <siretart> sistpoty: why?
[11:31] <sistpoty> siretart: because otherwise everyone could change the type of divergence?
[11:31] <siretart> sistpoty: a wiki doesn't need usermanagement, too
[11:31] <siretart> sistpoty: *Shrug*. wikipedia works too
[11:31] <sistpoty> siretart: it does... and it has revision control as well
[11:32] <lucas> siretart: I don't care, just generate or help me generate a text file with the MOTUNotes syntax
[11:32] <lucas> I can add several other columns to the reports if needed ;)
[11:32] <\sh> to be honest, we can't avoid to be different in some areas from debian, and we shouldn't want to avoid it. infrastructure reasons are one point, but special ubuntu patches or patches we can provide upstream is something else
[11:32] <siretart> \sh: I strongly disagree
[11:33] <siretart> \sh: I think we should avoid divergence where possible, because we are really lacking ressources
[11:33] <\sh> siretart: you can't force debian to apply our gnome patches e.g. for launchpad
[11:33] <sistpoty> \sh: the advantage would be to have "all packages with motuglutransition" at hand, and once debian and ubuntu are back in sync, this might save a lot of work
[11:33] <\sh> sistpoty: this is "infrastructure" which will go away
[11:34] <siretart> \sh: please don't overread the 'where possible and necessary' part. I certainly know that we want some divergence, but I think we have way too much of it
[11:34] <\sh> sistpoty: the same applies for transitions..as we saw from breezy to dapper :)
[11:34] <\sh> siretart: don't blame us, blame the slowliness of the transitions in debian...honestly
[11:34] <sistpoty> exactly, but what do you mean with infrastructure, that will go away?
[11:34] <siretart> \sh: I don't want to blame anyone, I want to solve problems
[11:35] <\sh> siretart: the system how debian works is really different from ours...and even if we're less people then debians DDs and NMs, we are quite faster in those transitions.
[11:35] <siretart> \sh: so what?
[11:35] <\sh> siretart: so you can't avoid it...and thinking about sabdfls speech at debconf5 those deltas are really normal
[11:36] <\sh> siretart: for ubuntu.
[11:36] <\sh> siretart: the solution is "time"
[11:36] <lucas> some of them are normal, some of them aren't
[11:36] <\sh> lucas: which aren't normal?
[11:36] <lucas> bugs fixed in ubuntu but not reported upstream, for example
[11:36] <siretart> \sh: http://tiber.tauware.de/~lucas/versions/unimultiverse.html lists about 900 packages, which of same upstream version in both ubuntu and debian (but ubuntu hast 'local' changes)
[11:36] <sistpoty> \sh: but I still think we might gain much time, if we could categorize the reason, why a package diverges from debian, whilst doing merges
[11:37] <lucas> we have to stay at a stable distance from debian. not increase this distance release after release
[11:37] <siretart> \sh: I suspect a big part of them to be unnecessary. and 900 diverged packages is definitly way to much for us
[11:37] <siretart> lucas: how often is that list updated?
[11:37] <\sh> ok ok..
[11:38] <\sh> short summary
[11:38] <\sh> what do we have:
[11:38] <lucas> every 6 hours
[11:38] <sistpoty> \sh: consider that you can just see: ah siretart last uploaded foo and transitioned it to c2a... debian/changelog states the same, then you'll only need to check if the debian package did it right
[11:38] <lucas> siretart: read http://tiber.tauware.de/~lucas/versions/ ;)
[11:38] <\sh> we have packages with more actual upstream version means  0UbuntuX
[11:38] <siretart> 82 packages
[11:38] <\sh> sistpoty: yes..that's what we did in dapper with the c2 transitions.
[11:39] <\sh> sistpoty: and we will do the same for dapper+1 with all c2a transitions
[11:39] <\sh> we have packages which were renamed from us, but not renamed by debian
[11:39] <\sh> (but will be in time)
[11:40] <siretart> \sh: please. 900 packages is really ridiculous. our main divergence should be in main, not in universe. we simply don't have the ressources to maintain it
[11:40] <\sh> we have packages, which have special ubuntu patches applied, those patches debian never will apply
[11:41] <sistpoty> \sh: yes, and that's the reason to categorize the divergence... to see if patches need to be reapplied or if it's probably a sync candidate
[11:41] <siretart> \sh: now you slowly get the point. I want a list where I can look of what kind of divergence (i.e. why the package was diverged from debian) a given package has
[11:42] <\sh> siretart: so we need a tool which fetches the debian source package and fetches the ubuntu source package and run a diff 
[11:42] <\sh> siretart: and we need someone who has knowledge about all the changes and he can classify them
[11:43] <buxy> \sh: people.u.c/~scott/patches/ :)
[11:43] <sistpoty> \sh: the tool is mom... but that doesn't classify them
[11:43] <siretart> \sh: and I'd propose lets do that marginally. everytime someone touches a package causing divergence or working on merges he should add a note what kind of divergence that package has
[11:43] <\sh> siretart: most propably we will find out, that our people were doing the dpatch/simple-patchsys way, debian is doing the diff.gz way...or the other way around...
[11:43] <sistpoty> hehe, buxy
[11:44] <ajmitch> \sh: sounds like a job for an unemployed motu like me ;)
[11:44] <\sh> siretart: and then we have ubuntu packages where we fixed a bug from our bugtrackers...
[11:44] <\sh> or simple .desktop files 
[11:44] <lucas> we could start by making very verbose changelog entries
[11:44] <buxy> siretart: if you keep that info somewhere, please make it parsable by a program so that I can make that information available together with "sctottish pacthes" for Debian maintainer
[11:44] <lucas> so we know *exactly* what changed
[11:45] <buxy> in the Package Tracking System
[11:45] <ajmitch> buxy: good idea
[11:45] <\sh> lucas: what means "verbose changelog entries" ?
[11:45] <siretart> buxy: I have in mind that this information is valuable to both debian and ubuntu, as it helps minimizing divergence
[11:45] <lucas> \sh: no need to read the rest of the debdiff to know what changed
[11:45] <buxy> because actually Debian maintainer can grab the diff but they don't always know why the changes have been made
[11:46] <\sh> lucas: added .desktop file is quite simple and meaning full...reading the source and debian/rules should be accomplished by someone who is working on packages at all
[11:46] <sistpoty> siretart: if we use revu logins, we already have a user-system... I guess I could easily h4ck up the merge list to store some catagories as well
[11:46] <\sh> lucas: that is wrong
[11:46] <\sh> lucas: because you need to know more then only the changelog and the diff.gz.
[11:46] <\sh> lucas: today one DD gave me an example....source package ppp
[11:46] <ogra_ibook> siretart, sistpoty, err, isnt revu2 supposed to be included in LP ?
[11:46] <siretart> sistpoty: we could also use revu for authentication. but I'm not convinced that we would need authentication at all, because I don't think there is much interest for vandalism with wrong entries
[11:46] <siretart> ogra_ibook: yes
[11:47] <ogra_ibook> siretart, sistpoty, in which case LP logins will apply ...
[11:47] <\sh> doko wrote after the merge something like this in the changelog: "
[11:47] <lucas> \sh: the changelog, if verbose enough, is enough to categorize packages
[11:47] <\sh> * Synchronise with Debian unstable.
[11:47] <\sh>   * Still keep the pppoe_on_boot stuff.
[11:47] <sistpoty> ogra_ibook: tiber isn't whitelisted for lp yet... if it was, I guess it would be trivial (at least from reading the interface specs)
[11:47] <siretart> ogra_ibook: yes. my point stand, I don't think that we would need authentication at all, but I could live with lp accounts
[11:47] <ogra_ibook> siretart, yup
[11:48] <sistpoty> siretart: if I make a web interface w.o. accounts, everyone could change the catagory... I don't like that
[11:48] <\sh> lucas: reading this, is verbose enough, because I know that we have a pppoe on boot functionality...reading the diffs but shows me, that this feature was just gone in the debian package long ago, but we need it
[11:48] <sistpoty> siretart: other possibility was to hack up lpbugs and handle this by bugs in malone
[11:49] <siretart> sistpoty: I want everyone to be able to change the category and even to introduce new categories
[11:49] <siretart> sistpoty: do you fear much vandalism?
[11:49] <sistpoty> siretart: i'm pretty paranoid ;)
[11:50] <buxy> \sh: and the interesting stuff is to understand why this feature is needed by Ubuntu and why it has been removed in Debian :) did the Debian maintainer have a nicer solution to the problem ?
[11:50] <siretart> what do others think? is there a big danger from vandalism?
[11:50] <\sh> buxy: no :)
[11:50] <sistpoty> siretart: possibility was to use wiki, but that would mean to have a "divergence" in catagories
[11:50] <\sh> buxy: that's why he complained today :)
[11:51] <\sh> buxy: but he didn't want to read the diff..but my opinion is, as package maintainer you should 
[11:51] <lucas> siretart: you need to be able to restore a previous version easily
[11:51] <lucas> siretart: I'm not sure such a page would be enough.
[11:51] <\sh> buxy: and if I need some more info, I'll ask the guy who did the merge :)
[11:51] <ajmitch> buxy: we'll always run into problems when we make some changes without proper understanding of the package, just for a quick fix :)
[11:51] <siretart> so we have 4 possibilities: (a) don't categorize since uneccesary work (b) categorize via wiki/MergeNotes (c) categorize via webtool and login (d) categorize via webtool without login
[11:51] <lucas> we need to be able to put a package into several categories
[11:52] <siretart> lucas: right
[11:52] <ajmitch> I know I'd even be wary of MOTUs patching some of my debian packages :)
[11:52] <sistpoty> and a user should be able to add a catagory
[11:52] <lucas> (e) categorize via bugs, or a specific interface in LP
[11:52] <sistpoty> :(
[11:52] <\sh> ajmitch: hmmm? :)
[11:53] <ajmitch> siretart: why no login?
[11:53] <ogra_ibook> sounds like a cool database project :)
[11:53] <lucas> we want knowledgeable people to do the tagging
[11:53] <lucas> so login is fine
[11:53] <\sh> ogra_ibook: long term :)
[11:53] <ogra_ibook> yup
[11:54] <\sh> oh wow...a lot to read for me for the minutes :)
[11:54] <slomo_> (hi btw, sorry for beeing that late, didn't notice that there was a meeting :/ )
[11:54] <sistpoty> hi slomo_
[11:54] <siretart> ajmitch: no login because I don't fear vandalism and I want to make it as easy as possible to use
[11:54] <ajmitch> slomo_: don't worry, I was 2 hours late
[11:54] <siretart> hi slomo_ 
[11:55] <siretart> ok, the majority seems to be (c)
[11:55] <ajmitch> slomo_: being 3 hours late is no obstacle, we're still going ;)
[11:55] <siretart> I think I'll meet with sistpoty in person and get details about this discussed with him, ok?
[11:55] <siretart> sistpoty: ok?
[11:55] <sistpoty> siretart: sure
[11:55] <ajmitch> ah, closed secret meetings? ;)
[11:55] <buxy> a town name please !
[11:55] <siretart> ajmitch: of course, secret cabal and such ;)
[11:56] <siretart> buxy: we are at the same university, in erlangen ;)
[11:56] <ajmitch> siretart, sistpoty: we need to discuss some REVU2 coding sometime also
[11:56] <Lathiat> motu m eeting?
[11:56] <sistpoty> buxy: erlangen probably, or nuremberg
[11:56] <siretart> ajmitch: right
[11:56] <ajmitch> Lathiat: yes
[11:56] <Lathiat> *still* going? :)
[11:56] <ajmitch> Lathiat: yes
[11:56] <buxy> hehe, the famous erlangen meeting !
[11:56] <Lathiat> ok :)
[11:56] <ajmitch> buxy: better than vancouver :)
[11:56] <siretart> lol
[11:56] <\sh> ejabberd is in erlangen 
[11:56] <sistpoty> ajmitch: oki
[11:57] <sistpoty> ok... what's left to discuss? date and time of next meeting?
[11:57] <siretart> I think so
[11:57] <siretart> 3h meetings are too long
[11:57] <sistpoty> definitely
[11:57] <ajmitch> yes
[11:57] <ajmitch> far too long
[11:58] <sistpoty> I guess it would be good just after uvf?
[11:58] <ajmitch> 2 weeks from now?
[11:58] <ajmitch> nah
[11:58] <lucas> siretart: please mail a summary of what you intend to do to ubuntu-motu. I'm interested in this :-)
[11:58] <\sh> wasnt it the first meeting after ubz?
[11:58] <ajmitch> lucas: they will have to
[11:58] <sistpoty> ajmitch: sure, that's what I call "just after uvf" ;)
[11:58] <lucas> siretart: and setup those backups for tiber ;)
[11:59] <siretart> lucas: I'll try :) - most of this was already said in my first post this year
[11:59] <ajmitch> lucas: I also want to discuss some things with you..
[11:59] <siretart> lucas: yes, thats on my list, too
[11:59] <siretart> next meeting in 2 weeks?
[11:59] <lucas> ajmitch: now ?
[11:59] <siretart> objections?
[11:59] <sistpoty> time, 20.00 utc?
[11:59] <lucas> time is fine for me.
[11:59] <ajmitch> lucas: whenever suits
[11:59] <Lathiat> mm 4am :)
[11:59] <sistpoty> time for objections left: 5
[12:00] <sistpoty> 4
[12:00] <ajmitch> sistpoty: hm, I'll be busy then
[12:00] <sistpoty> ajmitch: propose another time
[12:00] <\sh> 3...2...1...
[12:00] <ajmitch> nah, it doesn't matter
[12:00] <siretart> ok. I need to go now, sorry
[12:00] <buxy> ajmitch: you're an important face
[12:01] <sistpoty> no, we can't meet at 20.00h... -meeting is busy there
[12:01] <sistpoty> gn8 siretart
[12:01] <slomo_> bye siretart :)
[12:01] <siretart> I wish you a good night, sleep well everyone!
[12:01] <ajmitch> bye siretart 
[12:01] <\sh> sistpoty: put a date and time on the wiki page..I'll promote them in the minutes :)
[12:01] <buxy> we don't have so many people with double hat MOTU/DD outside of the core developers paid by Canonical
[12:02] <sistpoty> \sh: I vote for ajmitch to put it there ;)
[12:02] <ajmitch> buxy: no, I think I'm one of the few who can upload to main, universe & debian who's not employed :)
[12:02] <\sh> whatever :)_
[12:03] <ajmitch> sistpoty: 2000 UTC is 9am for me, I'm busy all that week of the 23rd-28th
[12:03] <ajmitch> so I can't hold others back
[12:03] <\sh> damn..I forgot to kiss ajmitch's feet while I had the time during UBZ ,)
[12:03] <ajmitch> \sh: you'd get a kick in the mouth :P
[12:03] <\sh> ajmitch: hehe :)
[12:03] <sistpoty> ajmitch: there is status meeting at 20.00 utc, so we can't meet at that time and I don't have any preferences