TZ UTC +1
{{{
09:46	mdz	good evening
09:46	ajmitch	hi mdz
09:47	ajmitch	devel team meeting, is it?
09:51	mdz	ajmitch: yes
09:52	mdz	roll call
09:53	bdmurray	present
09:53	_kyle	batman! er. nope, just me.
09:53	Riddell	hola
09:53	rtg	here
09:53	_kyle	(connected xchat since my ssh is all laggy)
09:53	kwwii	howdy all
09:55	mvo__	hello
09:55	mdz	cjwatson,heno,doko,BenC,pkl,asac,tkamppeter,Keybuk,pitti,fabbione,tfheen,iwj,ogra: ping
09:55	doko	pong
09:55	heno	pong
=== ogra waves
09:56	Keybuk	_o/
09:56	asac	hi
09:56	pitti	hello
09:57	cjwatson	here, just making coffee
09:58	mdz	BenC: is pkl around?
09:59	BenC	mdz: checking
09:59	tfheen	pong
09:59	BenC	cjwatson: coffee, sounds good
09:59	mdz	cjwatson: expecting till?
09:59	mdz	fabbione: ping
10:00	BenC	he's coming
10:01	fabbione	pong
10:01	fabbione	sorry i am late
10:00	mdz	ok, moving along
10:01	mdz	rtg: you started last week, but this is your first weekly meeting. welcome!
10:01	asac	rtg: hi!
10:01	rtg	Thanks.
10:01	Riddell	hi rtg
10:01	mdz	rtg is Tim Gardner, who I believe remains the newest addition to the kernel team
10:02	mdz	agenda is at https://wiki.ubuntu.com/DevelTeamMeeting20070215
10:02	mdz	any last-minute additions?
10:02	cjwatson	mdz: Till didn't say he wasn't coming
10:03	mdz	ok, moving right along

10:03	mdz	pitti: you're up
10:03	pitti	#
10:03	pitti	Do we want to use XSBC-Original-Maintainer (which works, modulo the small bug fix that is already prepared), or teach dpkg about a proper 'Original-Maintainer:' field?
10:03	mdz	there was some discussion about this by mail
10:03	pitti	so, the point is, XSBC- looks ugly, but works
10:04	iwj	We should use XSBC- for at least the next while, as I say.
10:04	pitti	the .debs, .dsc etc. have Original-Maintainer, so for users it's fine
10:04	tfheen	adding the field is trivial, but I don't know if Debian will take it.
10:04	iwj	Well, let's offer them the patch and if and when they take it and it's widely deployed we can switch to it.
10:04	pitti	so the effect won't change if we later teach dpkg about the new field
10:04	tfheen	iwj: why?  If we actually think it's a good idea, we should just go with O-M, IMO.
10:04	iwj	There's no harm of XSBC- in the meantime except that it's slightly ugly.
10:04	iwj	tfheen: Because people often run source-processing tools not on the distrorelease.
=== pitti agrees to iwj here, especially if we have tool support for making these changes
10:05	iwj	... that they are intended for.
10:05	iwj	I said all this by email ...
10:05	cjwatson	where was this e-mail conversation?
10:05	tfheen	distro-team@, iirc
10:05	pitti	replies to my activity report
10:05	cjwatson	ah, yes
10:05	iwj	Should it have been in ubuntu-devel ?
10:06	cjwatson	OTOH, failing to use XSBC- only has the consequence of an ugly error message, not build failures, IIRC
10:06	tfheen	cjwatson: correct.
10:06	mdz	iwj: yes
10:06	iwj	mdz: OK
10:06	pitti	cjwatson: and that the field doesn't actually appear in the debs/dsc?
10:06	tfheen	iwj: then I say we can just add it to our dpkg and those who don't use our dpkg can use XSBC-.
10:06	cjwatson	pitti: sure, but whatever
10:06	iwj	cjwatson: Err, using O-M when the tool doesn't support it means the field gets lost.
10:06	pitti	cjwatson: but that'd miss the point?
10:06	cjwatson	iwj: does that actually matter?
10:06	cjwatson	all we've promised to do is have it in our archive
10:06	iwj	tfheen: But the question is _what do we put in our packages_, which other people besides us touch too.
10:06	tfheen	pitti: the debs will be fine as they're built on the autobuilder.
10:07	mdz	there's no reason to use O-M in Debian
10:07	pitti	right, just .dsc
10:07	cjwatson	it makes no technical difference to the package
10:07	iwj	cjwatson: All universe maintainers are now to be forbidden from running dpkg-foobarpackage other than on feisty ?
10:07	cjwatson	oh, that's true, it would make a difference to the .dsc
10:07	cjwatson	in that case I agree with Ian
10:07	mdz	iwj: do you develop on Feisty?
10:07	iwj	mdz: Yes, but I run dpkg-signchanges on sarge.
10:08	tfheen	signchanges is irrelevant; -gencontrol is the interesting one.
10:08	iwj	tfheen: Yes, but this is turning into a complex set of rules that everyone has to get right.
10:08	cjwatson	I have in the past built Ubuntu source packages on Debian (quite regularly) and I see no reason why we should break that
10:08	iwj	XSBC- just works and we should use it.
10:08	tfheen	except it doesn't work correctly due to a bug?
10:08	iwj	What cjwatson said.  Sometimes I don't have a feisty install to hand.
10:09	pitti	tfheen: I have fixed that in my pending upload
10:09	iwj	tfheen: The bug we can get fixed in etch even probably.
10:09	pitti	well, cjwatson did the fix
10:09	tfheen	pitti: oh sure, but the "you can't build packages on !feisty" argument applies until it actually is in other stable releases.
10:09	pitti	tfheen: but the bug is irrelevant mostly, it only affects propagation to .debs, not to .dsc
10:10	tfheen	"can't" here meaning "will not have a 100% compliant .dsc", nothing will actually break.
10:10	pitti	tfheen: irrelevant for building source packages, that is
10:10	iwj	And why oh why oh why are we having this argument by IRC ??  IRC is a terrible medium for arguments.
10:10	tfheen	pitti: oh, ok.
=== pitti actually prefers discussing stuff synchronously
=== ogra too
=== tfheen prefers IRC over email any day.
10:10	cjwatson	I'm not hearing serious objections to XSBC-
10:11	pitti	I'm still in favour of eventually supporting O-M, but that's something for later
10:11	cjwatson	so I think we should do that and move on to the next of the several items on the agenda
10:11	cjwatson	pitti: sure
10:11	iwj	pitti: Yes.
10:11	cjwatson	* Can we find a sane method that dch can use to tell apart main from universe packages? If so, we could add an automatic change of [Original-] Maintainer:.
10:11	pitti	great
10:11	cjwatson	mdz addressed that on distro-team@
10:11	iwj	mdz was right.
10:12	pitti	ok, so we set it to $DEBEMAIL?
10:12	pitti	and warn if it's not m/ubuntu/?
10:12	cjwatson	no, leave it alone
10:12	Riddell	pitti: or kubuntu or edubuntu...
10:13	cjwatson	often you want it to be the relevant team mailing list instead
10:13	pitti	cjwatson: my q is about doing something if there's no O-M
10:13	pitti	I'm fine with fixing it manually, it's just a bit cumbersome
10:13	pitti	and, as doko noticed, pro/demotions will break the default ML values
10:14	cjwatson	I don't think we should mess with debian/control (or even Maintainer in the .dsc) automatically. It's far too fragile.
10:14	cjwatson	doko's point is valid but later on the agenda :-)
10:14	doko	heh
10:14	pitti	it's just closely coupled
10:14	pitti	anyway, if noone is in favor of automatic changing, lets go on
10:15	cjwatson	For main packages, should we rather use ubuntu-devel-discuss@ instead of ubuntu-devel@? If so, we need to change and sign off the spec.
10:15	cjwatson	addressed on distro-team@ (yes)
10:15	cjwatson	Do we need to get all packages fixed in Feisty? IOW, do we need mass-uploads or can we just slowly migrate the fields over time?
10:15	pitti	that's done
10:15	cjwatson	also addressed on distro-team@
10:15	cjwatson	handling of addresses where source/binary are in different pockets; CORE address for packages in universe.
10:15	pitti	not really
10:15	Keybuk	some packages built in feisty do not have equivalents in Debian
10:15	cjwatson	not really to which?
10:15	pitti	I'd really like to discuss the schedule here
10:15	Keybuk	so automatic modification would be wrong in that case
10:15	iwj	If we do nothing special, all the packages will be updated by feisty+1, right ?
10:15	pitti	cjwatson: slow/quick migration
10:16	pitti	iwj: we need to modify debian/control, that won't happen automagically
10:16	pitti	so, mdz and I had the compromise of fixing all 350-some main .debs for feisty
10:16	cjwatson	I'm with mdz on this; we are way behind on our commitment and we need to get it done
10:16	iwj	All of the .debs will be updated and not all of the .dscs, then ?
10:17	pitti	and do the source-only and universe ones with the feisty+1 merge
10:17	tfheen	iwj: not magically, no.  Just through churn.
10:17	pitti	I think that's fair
10:17	pitti	we have 750 main and > 1000 universe sources which need to be modified, and rebuilt by beta otherwise
10:18	pitti	and if we get new X.org packages anyway, a good chunk of the 350 .debs will already be sorted out
10:18	mdz	the source maintainer is much less visible, and unlikely to be noticed by users reporting problems with the package
10:18	pitti	(explanation: fixing the .debs is a matter of pure rebuild)
10:18	mdz	which is the source of the complaint
10:18	pitti	so we'd get the dpkg-source check into feisty now, so that we do not continue to upload sources with wrong maintainers
10:19	mdz	so fixing the remaining .debs is a solid incremental step toward finishing the job
10:19	mdz	as is fixing dpkg-source
10:20	pitti	ok, if we don't have further comments, I'll care for the rebuilds and take doko's gcc changes into account
10:21	cjwatson	ok
10:21	cjwatson	* handling of addresses where source/binary are in different pockets; CORE address for packages in universe.
10:21	pitti	doko: ^ you need some rebuilds?
10:21	Riddell	win 12
10:21	pitti	I think for this only source packages matter
10:21	Riddell	erk
10:21	cjwatson	source/binary is irrelevant, as discussed on the list
10:21	doko	pitti: yes, I'll send you the list; please start after GCC-4.1.2 is in the archive
10:21	pitti	doko: ETA?
10:22	doko	after the freeze ends. tfheen ?
10:22	pitti	doko: ah, that's fine
10:22	cjwatson	* Promotion/demotion invalidates the address.
10:22	mdz	regarding promotion/demotion, I'm personally not fussed
10:22	cjwatson	I suggest that somebody write a tool which points out the inconsistencies, and we can garden it from time to time
10:23	mdz	this is much more about masking the original address than providing the best contact
10:23	cjwatson	much like the other such tools we already have
10:23	pitti	if people set it manually anyway, then we hopefully will get more specialized teams or individual maintainers anyway
10:23	cjwatson	but I agree it is not urgent
10:23	tfheen	doko: freeze ends tonight; It seems the current set of ISOs is good, so I'll release them tonight and thaw the archive, then send out the announcement tomorrow morning.
10:23	mdz	they'll be fixed when rebuilt
10:23	pitti	we actually need to rebuild such packages anyway for translation changes
10:23	mdz	ok then, it's only an issue for the source, so even less urgent to change things
10:23	doko	tfheen: just ping me when I can upload (if it's before bedtime)
10:24	mdz	so we're all clear on debian-maintainer-field now?
10:24	pitti	yes, sorry for the abundance of questions
10:24	pitti	but this affects so many packages that we should get it right at the first shot
10:25	mdz	agreed, thanks
10:25	mdz	pitti: I answered you about apport-retrace on the list; I think it's very useful, but we're behind on a few higher-priority items where you might be able to help out if you have spare cycles
10:25	pitti	right, got that
10:25	mdz	pitti: did you already talk with Scott about your tasks?
10:25	pitti	spare cycles go into bug fixing, but I'm happy to help out with specs where appropriate
10:26	pitti	mdz: not yet, I was away in the evening, sorry
10:26	cjwatson	* ISO release testing (Henrik Omma): I think we should decide before Beta whether we are going to actually use the Malone-based tracker. Are people comfortable with it or is the wiki better after all? Simon, Tollef: are you two leading beta release/testing together or do I have a key part in this (beyond the community-based contribution)?
10:27	Riddell	it works well enough from my point of view
10:27	heno	It seems to have worked fairly well today
10:27	pitti	personally I found the wiki much better for getting an overview of the overall state, but bugs parallelize better
10:27	ogra	++
10:27	cjwatson	heno: on the latter item, I'd like you to lead the testing side of this, since you've been making good progress with it so far
10:27	heno	that is true
10:27	tfheen	I'm much happier this time than the previous time.
10:27	cjwatson	heno: let's talk about that on the phone tomorrow?
10:28	cjwatson	tfheen: are bug comments from individual testers getting through to you effectively?
10:28	heno	cjwatson: ok, s long as it's clear that I'm doing it
10:28	mdz	pitti: can you think of a way to improve the overview using the bugs?
10:28	heno	cjwatson: sure
10:28	tfheen	cjwatson: we haven't really had many individual testers, but yes, I have subscribed to the product.
10:28	cjwatson	heno: thanks, I appreciate it
10:28	pitti	mdz: we could use bughelper to create a report
10:28	mdz	heno described a scheme using the status field to provide a sort of overview, though of course it requires someone to maintain the state
10:28	ogra	mdz, a generated table overview ?
10:29	heno	people who post a result can update the state
10:29	ogra	that would need to parse the bugtexts though
10:29	heno	wejust need good etting of testers
10:29	cjwatson	heno: I don't think that will happen in practice
10:29	tfheen	pitti: I need to chat a bit with dholbach about bughelper, I guess; I really want to generate reports from malone and can't today.
10:29	pitti	a mere matrix with the current bug states would already be helpful, I figure
10:29	heno	to make sure they are clued in and committed
10:29	tfheen	not just for ISO testing, but also for other release metics.
10:29	cjwatson	and it would be best if the amount of education of testers required is as small as possible
10:30	mdz	I don't see how bughelper helps, can you explain?
10:30	heno	I envision just a small group of 'trusted' community testers this cycle
10:31	heno	mdz: it can scrape useful state info from the bug pages
10:31	cjwatson	I'm worried that we'll swamp a small group; it's a lot of work even for full-time staff
10:31	pitti	mdz: I meant, using the bughelper library to find the bugs and get their states, and then cobbling together some HTML report
10:31	heno	and present them in an html table
10:31	pitti	heno: :)
10:32	tfheen	cjwatson: yes, it should be possible to just jump in and test a single ISO without having to go through a big process to do so.
10:32	mdz	what would that tell you which wouldn't be visible from the table on the iso tracker bug page?
10:32	heno	so we get a non-editable 'wiki' page powered by the malone content
10:32	ogra	the problem is that finer grained info like the different install variants is only in the bugtexts
10:32	pitti	mdz: we could count number of testers, parse out the ok/fail comments, parse out bug numbers to make them clickable, etc.
10:32	tfheen	mdz: the malone bug page is going to be unwieldy when we have the full test cases there, as we will for beta, RC and release.
10:33	heno	ogra: no we will do separate bugs for those in later milestones
10:33	ogra	ah, cool
10:33	mdz	pitti: oh, I see, using the format conventions described in the docs
10:33	mdz	it looked like some people were using those at least
10:33	heno	so there will be very many tracker bugs
10:33	heno	so an overview html page is a must really
10:33	mdz	tfheen: no more unwieldy than the wiki page, and probably less
10:34	heno	I think it would be worse tha the wiki
10:34	heno	unless you filter by tags
10:34	pitti	. o O { using an apport GUI to create a report with parseable standard syntax, yummy }
10:34	cjwatson	perhaps we can brainstorm mad ideas by mail? :-)
10:34	heno	but the bughelper hack should be easy
10:34	heno	yep
10:35	heno	I'll prepare something
10:35	tfheen	but as I said, I'd really like to be able to pull statistics out of malone since I can't today and I'd love to for a release status page.
10:35	heno	(email with ideas)
10:35	cjwatson	ACTION: heno, tfheen, pitti etc. to discuss and prepare status overview page for ISO tests
10:35	heno	tfheen: that's doable
10:35	heno	ok, done :)
10:36	mdz	[UbuntuSpec] increase-hwdb-participation (Sebastien Bacher): do we need a menu item for hwdb participation? that's something that is likely to be launched once only and will clutter the menu then
10:36	mdz	the point here is that we want it to be obvious how to contribute to the database
10:36	seb128	and we want to keep the menus or shell not too long if possible
10:36	pitti	heads-up: right now we have an one-time notification pointing people to the menu item
10:36	mdz	and we do want people to contribute again if their hardware changes
10:36	seb128	because many items make them hard to use
10:36	ogra	we discussed that the other day in -devel ... the most proper solution (having a button in the notofocation) braks the notofocation policy
10:36	pitti	we can easily point people somewhere else
10:37	ogra	meh ...
10:37	seb128	well, there is a button to do that to hal-device-manager
=== ogra goes for a typing course
10:37	kwwii	why not put it in System-->Administration ?
10:37	mdz	seb128: no one knows that is there
10:37	pitti	no, no button in the notification, that'd be wrong
10:37	seb128	we can point people to h-d-m
10:37	ogra	right
10:37	seb128	mdz: we display a notification bubble if I understood that correctly
10:37	ogra	without the control center i agree ...
10:37	seb128	mdz: we could point people to hal-device-manager
10:37	tfheen	seb128: yes, we do that today already.
10:37	mvo	we already have a lot of icons in the control-center, I don't think it will get worse
10:37	ogra	yep we do
10:37	heno	we could mention it on the default firefox homepage
10:38	seb128	mvo: we try to reduce the list
10:38	heno	(if people look at that)
=== mvo is not sure if people actually read that ff page
10:38	seb128	mvo: we should not start accepting random icons because the list is already long, that's not a reason to make it longer
10:39	pitti	another option is to just open hwdb-client right away on first login
10:39	seb128	what would be wrong with pointing people to h-d-m?
10:39	cjwatson	pitti: ugh
10:39	pitti	but I understand that contradicts our 'no wizards' policy
10:39	ogra	i'm not opposing to point to h-d-m ... if users dont have to wait for control-center and have to search there
10:39	mvo	I think the new g-c-c concept does not work very well, but that is a different discussion
10:39	mdz	heno: that's not a bad idea
10:39	pitti	cjwatson: ugh indeed :/
10:39	seb128	grrraa
10:39	heno	I agree with seb128 on this, and icon for a one-time item is a bit much
10:39	seb128	please stop the constant ranting on the shell
10:39	seb128	I already said we will switch back to menu
10:39	tfheen	seb128: I think the new shell is much better.
10:39	mdz	to return to the issue at hand...
10:39	heno	we could make it quite prominent on the FF page
10:39	seb128	(that's especially for ogra and mvo who keep telling that every day)
=== mvo hugs seb128
10:40	pitti	heno: you just cannot open programs with HTML links
10:40	ogra	right ..., thats why i'm not opposed to drop the menu item completely
10:40	mdz	we're concerned with the use case "I want to submit my system profile to the Ubuntu hardware database"
10:40	ogra	seb128, ^^^
10:40	pitti	ogra: people have to find it again if HW changes
10:40	seb128	tfheen: it still has some bugs and could be faster, it's likely to be default upstream next cycle
10:40	heno	pitti: right but you can show a screenshot with colourful arrows :)
10:40	ogra	pitti, but then they have seen it once at least
=== pitti thinks that in fact most of the things in c-c will only be used once, so *shrug*
10:41	seb128	mdz: well, that mean the menu item will be used like once a year (you don't change config every week usually)
10:41	seb128	mdz: and it'll be in the way the rest of the time
10:41	heno	pitti: actually you can, with a custom mime-type
10:41	mdz	seb128: agreed, it's rarely used
10:41	pitti	seb128: neither do users change their theme or keyboard layout
10:41	seb128	pitti: those are configuration tools
10:41	pitti	heno: urgh :)
10:42	seb128	pitti: and people might play with theme more often than you think
10:42	heno	filename.launch-hwdb :)
10:42	pitti	seb128: sure
10:42	seb128	but that's not the point
10:42	mdz	seb128: the data we collect from it is very important, and if users don't see it, they don't participate.  I agree with your concerns about the menu, but how else can we present it where users will discover it?
10:42	seb128	I'm just trying to keep the list of menu or shell items not too long
10:42	pitti	another idea:
10:43	seb128	mdz: we have a notify bubble, pointing them to hwdb menu item or hal-device-manager is about the same no?
10:43	pitti	how'bout adding it to update-notifier? people would get a tray icon and if they click on it, it'd open h-c, and then the icon would disappear
10:43	mvo	we could do it as a post-install note
10:43	seb128	mdz: h-d-m is also to the menu and it has a button to run hwdb-client
10:43	heno	can we make it very prominent during testing and much less at release time?
10:43	mvo	u-n has support for this already
10:43	mvo	it can even include scripts
10:43	ogra	i really think it doesnt needed an extra menu entry ... and if i remember correctly that was the initial polcy when mdz assigned the project to me ...
10:43	tfheen	pitti: and then readd the icon if the hardware changes?
10:43	pitti	tfheen: that's harder
10:44	ogra	i had a bunch of whishlist bugs that made it appear
10:44	heno	the people who run feisty are the most likely to participate anyway
10:44	seb128	pitti: well, that's what I said before, use a notification area icon, that would work too
10:44	tfheen	pitti: not really; store a md5sum of the lspci output or something somewhere and check that on login.
10:44	pitti	tfheen: but it would bring people to it once, and then we can hide it behind h-d-m and explain where it is in the icon notificatino
10:44	mdz	ogra: it originally had a menu entry; it was removed during one of the menu cleanups
10:44	pitti	tfheen: and usb, and there it gets trickier
10:45	mdz	pitti: isn't that what the increase-hwdb-participation spec was meant to be?
10:45	ogra	mdz, the first hoary version only had the h-d-m button ... in breezy i added the menu entry mainly because kubuntu complained ...
10:45	mdz	pitti: notify the user once?
10:45	pitti	mdz: it talks about a notification, not a tray applet
10:45	heno	When we get a slideshow in ubiquity we can show it there
10:45	mvo	pitti: we have the post-install notifications in u-n, we could use those
10:45	pitti	mdz: from a notification we cannot launch programs, but from a tray icon we can
10:45	mvo	they are there and ready (and support scripts)
10:46	pitti	well, we can launch programs from notifications, but it is *very* ugly usability-wise
10:46	cjwatson	this item is dragging on somewhat
10:46	mvo	the u-n post-install hooks have a dialog that contains a button. nice text + button
10:46	seb128	let's use that then
10:46	pitti	mvo: sounds good
10:46	tfheen	a problem with regular notifications is they disappear, so if you don't pay attention, they go away and you can't get them back
10:46	tfheen	so interacting with notifications is bad.
10:46	mdz	so long as the user is inivted to participate when they install, I'm happy
10:47	mdz	either launching the client directly or providing simple instructions
10:47	mvo	pitti: lets check this out tomorrow together, ok?
10:47	pitti	mvo: yes
10:47	mdz	opening device manager and finding the button is not simple enough, though
10:47	mdz	ACTION: mvo/pitti to review options for hwdb notifications
10:47	mdz	moving on
10:47	pitti	mdz: the install note could explain where it is
10:47	mdz	Maintenance "costs" of python debug packages (Matthias Klose)
10:48	pitti	(this was about maintaining a large delta from Debian for the -dbg packages, since Debian is frozen ATM, and hasn't decided yet whether to adopt it)
10:49	pitti	and the debian/rules code for that is nontrivial
10:49	pitti	doko: ping ^
10:50	doko	yes, the thing is, if we want/can afford it. it's a diff for every package we want to build extensions
10:50	doko	in debug mode.
10:50	cjwatson	I thought we had discussed this already
10:50	mdz	I'm afraid I don't have the context
10:50	cjwatson	how many packages are involved?
10:50	doko	about 50 in main
10:50	cjwatson	in fact I'm sure I spoke with you about this before and said yes
10:50	mdz	oh, this is for debug packages for extension modules?
10:50	cjwatson	50? yes
10:50	doko	ok
10:50	mdz	why doesn't the autobuild infrastructure handle that?
10:50	cjwatson	mdz: needs two build passes
10:50	mdz	oh, right
10:50	doko	debug mode needs a separate compilation
10:51	mdz	ok, sounds like this has been resolved anyawy
10:51	mdz	anyway
10:51	mdz	Document bug escalation to release team (Tollef Fog Heen): Started, but I want to agree with Simon about it before writing it down on the wiki.
10:51	mdz	this sounds like an action, not an agenda item
10:51	doko	ok, was just brought up today on #u-d
10:51	mdz	anything to discuss?
10:51	mdz	tfheen: ?
10:51	tfheen	mdz: no, I'm not sure why it ended up on the agenda.
10:51	cjwatson	tfheen: write it down first, then discuss it. :-)
10:51	mdz	ok, moving on
10:51	tfheen	I should have taken it off; sorry.
10:51	cjwatson	scott's/my fault for it ending up there.
10:51	mdz	iwj/asac/pitti: firefox ready to go?
10:52	asac	waiting for unfreeze
10:52	iwj	I spoke to asac in quite a bit of detail.
10:52	Keybuk	tfheen: you listed it under "Agenda Items" :p
10:52	asac	i will go one more time and polish changelog but then pitti will sponsor upload :)
10:52	tfheen	Keybuk: I must have been asleep; sorry.
10:52	cjwatson	asac: (you don't need to wait for the freeze to end in order to have an upload made)
10:52	mdz	asac: note that it can be uploaded during the freeze, and will just wait in the queue
10:53	mdz	in fact that's preferred
10:53	pitti	asac: will do after the meeting
10:53	asac	hmmm ... thanks ... didn't know that ... misunderstood pitti then :)
10:53	cjwatson	the queue in question is visible at http://people.ubuntu.com/~tfheen/unapproved-queue/feisty/
10:53	mdz	ACTION: upload firefox (pitti, asac)
10:53	tfheen	Keybuk: actually, it was under "action items", not "agenda". :-P
10:53	mdz	discuss adept-notifier integration of apport (pitti/Riddell)
10:54	pitti	so, we did that, and Riddel meant, that it should be fairly straightforward to port the update-notifier code to adept-notifier
10:54	mdz	has that happened?
10:54	Riddell	nope
10:54	pitti	and we definitively want to have it done
10:54	Riddell	it's on my todo for next week
10:54	pitti	mdz: the discussion, yes, not the porting
10:54	mdz	Riddell: I meant the discussion
10:54	Riddell	oh, yes, we discussed
10:54	mdz	ok
10:55	Keybuk	tfheen: sorry, then it was me that was asleep :p
10:55	Riddell	and apport is on the herd 4 CDs
10:55	mdz	iwj to write up summary of experiences debugging udev
10:55	iwj	udev> I haven't made a proper writeup but I have a few replies to bug reports which document some of the udev debugging procedures and which would make a reasonable source text.
10:55	mdz	Keybuk: ^^ I thought that was your todo?
10:55	Keybuk	mdz: I asked iwj to summarise his thoughts as well
10:55	iwj	He palmed it off on me, since I, err, volunteered.
10:55	mdz	ah, ok
10:55	Keybuk	more as a "how can we improve this?" rather than "what to do"
10:55	Keybuk	the "what to do" is still mine
10:56	mdz	and we already reviewed the bug escalation item
10:56	mdz	tfheen: release readiness?
10:56	Riddell	I'm good except for powerpc CDs
10:57	Riddell	but I believe that's the case for ubuntu and edubuntu too
10:57	ogra	me too except one ppc kernel bug
10:57	mdz	oh, speaking of powerpc
10:57	mdz	those are no longer release blockers ;-)
10:57	Riddell	so we don't care :)
10:57	tfheen	mdz: I'm putting together a list of indicators on how ready we are (bug trends, oversizedness, etc) which I am going to put into some tool and put that on a web page somewhere.
10:57	Keybuk	<mdz> with all due respect, ...
10:57	tfheen	I don't have any numbers to give you, but the current state is looking good.
10:58	tfheen	herd 4 is slightly delayed, but this is due to external factors, not bugs popping up in the distro.
10:58	Keybuk	the bit where they forgot to turn Soyuz back on?
10:58	tfheen	slightly as in I am doing the release now and not 12 hours ago.
10:58	Keybuk	or something else?
10:58	tfheen	Keybuk: yes, that bit in particular.
10:58	mdz	what's needed in terms of infrastructure changes for the powerpc transition?
10:58	mdz	cdimage bits?
10:59	cjwatson	we're going to start considering powerpc as part of ports, yes?
10:59	tfheen	I'm not sure; Colin knows that bit of cdimage much better than I since he set it up.
10:59	fabbione	moving ppc to ports as of debs is not going to be easy
10:59	cjwatson	also actually moving it to ports.ubuntu.com, which will be Hard
10:59	fabbione	cjwatson: probably impossible any time soon
10:59	cjwatson	because that requires per-release mirroring
10:59	mdz	cjwatson: yes
10:59	cjwatson	fabbione: it's not impossible, it's just work
11:00	mdz	I don't see any hurry with the .debs
11:00	fabbione	cjwatson: it's difficult for how it works now
11:00	cjwatson	fabbione: "impossible" means "cannot be done even if work goes into it". Don't exaggerate.
11:00	mdz	but we should move it out of the standard cdimage set
11:00	cjwatson	that's fairly easy
11:00	fabbione	cjwatson: the split at the moment is done with 2 rsync set of filters and not via dists/.. so it's difficult at the moment
11:01	cjwatson	yes, i.e. "work"
11:01	cjwatson	ACTION: cjwatson to move powerpc out of standard cdimage set
11:01	cjwatson	(ten minutes)
11:01	tfheen	cjwatson: If possible, I'd like to do it together with you.
11:02	cjwatson	sure
11:02	cjwatson	Keybuk: ^-- add tfheen to that
11:02	tfheen	I know the basic bits of cdimage, but knowing it better is good.
11:02	cjwatson	(assuming you're collecting items)
11:02	cjwatson	* Other business
11:02	Keybuk	cjwatson: yup
11:02	mdz	anything else outstanding?
11:03	BenC	big pat on the back to everyone
11:03	mdz	ok, thanks everyone and good night
11:03	seb128	thank you mdz
11:03	mdz	onward and upward
11:03	pitti	thanks, fellows
11:03	asac	thanks ... good night!
11:03	mvo	good night!
11:03	ogra	thanks
11:03	BenC	thanks everyone!
11:03	seb128	'night
11:03	cjwatson	next time let's have less discussion in the meeting. :-)
11:03	fabbione	night everyone
11:04	pkl_	good night
11:04	doko	good night
11:04	kwwii	night all...that was, erm, fun
11:04	bdmurray	night all}}}