19:30:01 <nirik> #startmeeting FESCO (2010-07-13)
19:30:01 <zodbot> Meeting started Tue Jul 13 19:30:01 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:01 <nirik> #meetingname fesco
19:30:01 <zodbot> The meeting name has been set to 'fesco'
19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:01 <nirik> #topic init process
19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:06 <mjg59> Afternoon
19:30:11 <kylem> evening.
19:30:18 <pjones> night.
19:30:28 <nirik> #info mclasen is unable to attend today, and will be out the next 2 weeks as well. ;(
19:30:31 <ajax> i reject your classist linear notion of time
19:30:43 <ajax> on that note, i'll be gone next week as well.
19:31:02 <notting> as will i!
19:31:52 <nirik> ok.
19:31:53 * cwickert is here
19:32:05 <smparrish> afternoon all
19:32:37 <nirik> ok, lets go ahead and get started I guess...
19:32:48 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:32:49 <nirik> .fesco 351
19:32:50 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:33:07 <nirik> lmacken wrote up some bodhi karma stuff
19:33:26 <nirik> https://fedoraproject.org/wiki/Bodhi
19:33:38 <nirik> jlaska: any new news on autoqa?
19:33:46 <kylem> sorry, i didn't get around to writing up my bit this week. :\
19:33:50 <nirik> do we wish to adjust the current karma settings? or leave them as-is for now?
19:34:00 * lmacken will also be pushing out a new bodhi update today, so last-minute changes are welcome
19:34:09 <lmacken> I'll be disabling the critpath karma requirements for EPEL as well
19:34:20 * nirik was just going to ask about that.
19:34:29 <lmacken> I'll also link up to the new bodhi/package acceptance docs, and make them obvious
19:35:19 <nirik> lmacken: so the only bodhi change not yet in is the enforcing 1 week in testing? or is that set now too?
19:35:59 <lmacken> nirik: that has yet to be implemented, but I'll give it a hard look today.
19:36:06 <nirik> ok.
19:36:26 <nirik> so, any adjustments wished for by fesco folks at the current time? or shall we move on?
19:37:03 <ajax> i'm still looking at bocheca's proposal, but nothing for right now
19:37:03 * nirik will move on in a minute if no one speaks up.
19:37:26 <nirik> yeah.
19:37:40 * kylem also, moving on is ok with me.
19:37:40 <nirik> ok, moving on to the next / related ticket:
19:37:43 <nirik> #topic #382 Implementing Stable Release Vision
19:37:43 <nirik> .fesco 382
19:37:44 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
19:38:00 <mjg59> I've added some notes for the exception process
19:38:03 <nirik> lets go over each.
19:38:14 <nirik> mjg59: where? to the wiki page?
19:38:17 <mjg59> Yup
19:39:23 <nirik> https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas#Stable_releases_should_provide_a_consistent_user_experience_throughout_the_lifecycle.2C_and_only_fix_bugs_and_security_issues
19:39:26 <nirik> (what a link)
19:40:05 <jlaska> nirik: sorry, just saw this irc ping about autoqa ... since I missed the #topic, I can reply in the minutes on devel@
19:40:19 <nirik> jlaska: ok, no worries.
19:40:58 <cwickert> I still consider this a big mistake. by *only* fixing bugs and security issues we abandon features, and this is one thing why many people use Fedora
19:41:09 <nirik> mjg59: those both look reasonable to me... what about 'leaf packages (where nothing depends on that package) where upstream fixes bugs and adds features in a mix"?
19:41:16 <jlaska> nirik: quick version, looking to have just the depcheck test running by F14-Alpha ... and several additional tests/enforcing tests online by F14-Beta
19:41:25 <nirik> jlaska: cool!
19:41:37 <mjg59> cwickert: You're free to take that up with the board
19:41:45 <ajax> cwickert: rawhide is -> that way.
19:42:13 <cwickert> if we have a separate feature channel, I'm fine with that, but we must make sure that the early adapters that are our target audience still have what they like most about fedora
19:42:21 <drago01> someday we will have KojiRepos or whatever they are supposed to be called ....
19:42:29 <smparrish> cwickert: I agree
19:42:38 <mjg59> I agree that it'd be desirable to make it easy for people to obtain new feature releases without having to track rawhide all the time
19:42:42 <pjones> our task isn't to decide that, but rather to implement the board's vision.
19:43:01 <nirik> I think some upstreams don't release in a way that fits 'only bugfix/security'... so we need some way to handle them...
19:43:15 <cwickert> I think if the board is doing something wrong, it is on us to say there is something going wrong
19:43:18 * nirik nods. So, perhaps we should ask the board to clarify that.
19:43:27 <cwickert> anyway, I will write to the board list
19:44:07 <nirik> mjg59: thanks for working on that...
19:44:14 <nirik> lets go over the other assignments?
19:44:17 <nirik> notting to work on Fedora 14: Document this stance in maintainer docs and announce to maintainers the new docs.
19:44:26 <mjg59> nirik: I suspect that almost all code we ship (given a support cycle of 13 months) will either (a) not have a security hole, because it was introduced later or (b) can have the patch backported without trouble
19:44:29 <notting> nirik: not done yet. started, but not finished enough to be a postable draft
19:44:37 <nirik> notting: ok.
19:44:39 <nirik> SMParrish to work on Fedora 14: metrics on how many updates each branch gets including rawhide?
19:45:08 <smparrish> nirik: got some numbers should have a draft ready to post tomorrow.  Full plate this past week
19:45:47 <nirik> mjg59: perhaps. I personally wonder about the calibre package I maintain... they release about 1 to 2 times a week. It's a mix of bugfixes and new features. Do I only push the one at f13 release and never again until f14? thats a lot of change and a very stagnet f13 one.
19:45:52 <nirik> smparrish: cool.
19:45:59 <nirik> nirik to work on Fedora 14: Some way to document failures to quality and consistency so we can learn from them, and see that the incidence is decreasing.
19:46:10 <nirik> I created: https://fedoraproject.org/wiki/Updates_Lessons
19:46:25 <nirik> please do add updates issues you know about from the past. I was going to ask QA folks to add as well.
19:46:37 <nirik> kylem to work on Fedora 14: Have an updates-features optional repository.
19:47:17 <notting> nirik: apparently there was something about packagekit & selinux recently (see the list)
19:47:22 <cwickert> nirik: good work, but you forgot the famous update of dbus, that broke packagekit
19:47:32 <kylem> unfortunately, i didn't have a chance to write this up yet. (been busy every night this last week)
19:47:48 <nirik> cwickert: yes, I hadn't had a chance to add it yet.
19:47:57 <nirik> notting: yeah, saw that one... will add.
19:48:09 <nirik> kylem: yeah, no worries.
19:48:40 <nirik> ok, so thats an update... shall we just keep working for another week, and go from there?
19:48:47 <nirik> anything more we wish to do right now on it?
19:49:35 <nirik> ok, then I guess move on?
19:49:49 * nirik waits for yells then moves on
19:50:02 * mclasen comes in late
19:50:06 <nirik> #topic #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13
19:50:06 <nirik> .fesco 387
19:50:08 <zodbot> nirik: #387 (compile list of supported CPUs and react to recent loss of support for Geode LX on F13) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/387
19:50:11 <nirik> welcome mclasen
19:50:18 <nirik> so, glibc is fixed in f13 here.
19:50:32 * cwickert cheers
19:50:33 <kylem> i mailed the binutils list, and got some response from hjlu asking me to make some modifications, which i've done this afternoon.
19:50:48 <kylem> nobody has screamed yet though.
19:51:02 <cjb> hurrah.  thanks, kylem!
19:51:11 <nirik> kylem: looks like the glibc patch was applied too...
19:51:18 <kylem> great.
19:51:24 <kylem> hopefully this won't be a problem now or in the future then.
19:51:26 <kylem> :)
19:51:41 <nirik> ok, so for f14+ we say this continues to be supported?
19:51:44 <mjg59> Phew
19:51:48 <mjg59> nirik: I think so
19:52:02 <mjg59> cjb: If this breaks before f14, can you scream at us?
19:52:07 * nirik is fine with that. Can we have votes to that effect?
19:52:08 <smparrish> nirik: Support should continue
19:52:09 <ajax> kylem: thanks for working on this.
19:52:12 <nirik> do we need a release test?
19:52:24 <cwickert> yes, I think we should test it
19:52:26 <mjg59> If someone wants to boot on an XO, that's be nice
19:52:44 <cwickert> I think it is a perfect legitimate test case
19:53:37 <nirik> ok, can someone mail the test list asking to add a test case for this?
19:53:38 <ajax> remind me exactly which subarch we're promising here?  geode lx?
19:53:43 <nirik> yeah.
19:53:43 <notting> right, but we don't have a budge for 'getting fedora QE specific hardware'
19:54:02 * nirik has a olpc here... I can test it if noone else is able.
19:54:06 <mclasen> don't we have a few olpc machines floating around ?
19:54:14 <kylem> i've got one now, thanks to cjb.
19:54:15 * cwickert has two
19:54:51 <cwickert> I will test until next week and then report back, ok?
19:54:52 <nirik> heck, I can stick mine up on the net and make it a test machine with packager access probibly.
19:55:06 <cjb> sounds like we're in fine shape
19:55:13 <nirik> the thing is that we want there to be a test of this as part of the release criteria, so we don't forget it right before f14.
19:55:30 <cwickert> +1 for being a release criteria
19:55:37 <smparrish> +1
19:55:37 <nirik> +1 here as well.
19:55:43 <cjb> yep.  do you want to add it to the release criteria, and put me down as someone willing to make sure the testing happens?
19:55:48 <cjb> (even if I just poke someone else to do it)
19:55:48 <ajax> +1 geode lx is a release criteria
19:56:03 <nirik> cjb: can you mail the test list asking for that? I'm not sure off hand where it goes, but they can help you add it there.
19:56:08 * notting would narrow it even more to 'XO 1.0 is a release criteria'
19:56:10 <pjones> I agree, +1
19:56:16 <notting> cjb: i'm assuming 1.5/1.75/etc. all are fine
19:56:21 <cwickert> +1 to notting
19:56:22 <cjb> notting: yes
19:56:27 <pjones> (but I do prefer notting's language)
19:57:16 <smparrish> cjb: 1.75 is still a via chip or is that going arm?
19:57:19 <nirik> #agreed xo 1.0 should be added to release critera and tested for the next cycle.
19:57:22 <cjb> smparrish: arm
19:57:35 <notting> cjb: oh, so 1.75 *doesn't* actually work in released fedora. heh.
19:57:37 * nirik used nottings wording... any objections?
19:57:50 <kylem> sounds good to me.
19:57:51 <nirik> notting: f12 is available... thats a released fedora. ;)
19:58:22 <nirik> speaking of f12... shall we move on to our next topic?
19:58:34 <cwickert> yes please
19:58:42 <nirik> Thanks for all the work on this cjb / kylem
19:58:45 <nirik> #topic #416 Set EOL Date For Fedora 12
19:58:46 <nirik> .fesco 416
19:58:47 <zodbot> nirik: #416 (Set EOL Date For Fedora 12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/416
19:58:58 <cjb> (thanks everyone!)
19:59:14 <pjones> I say we EOL it tomorrow.
19:59:20 <cwickert> +1
19:59:20 <nirik> not sure eol on a monday is good...
19:59:21 <pjones> too soon?
19:59:32 <cwickert> F13 is fine, who cares about F12?
20:00:20 <pjones> nirik: why not?
20:00:34 <kylem> i never could get the hang of mondays.
20:00:35 <pjones> it's not like a release; there's not a giant chance for something to go wrong.
20:00:41 * nirik shrugs. I guess it doesn't matter, unless rel-eng has a pref
20:00:50 <nirik> so why not that friday?
20:00:59 <nirik> I guess if there had to be a post eol update push.
20:01:46 <kylem> i'd suggest we postpone it an entire week to avoid the holiday.
20:02:02 <kylem> what's one week, and it saves any suprises from people taking long(er) weekends and such.
20:02:14 <pjones> kylem: that's what the ticket suggests...
20:02:20 <mjg59> Yeah, seems fine
20:02:37 <nirik> isn't the 29th just before the holiday tho?
20:02:48 <pjones> 29th is just after.
20:02:51 <notting> depends on which holiday you're referring to
20:03:05 * cwickert wonders who cares about american holidays anyway
20:03:09 <pjones> thanksgiving is the 25th
20:03:18 <nirik> oh, right.
20:03:19 <kylem> oh. i was just assuming.
20:03:27 <nirik> ok, 29th is fine with me.
20:03:31 <kylem> my thanksgiving is in october, tyvm. :)
20:03:37 <nirik> votes?
20:03:46 <cwickert> +1 for 29th
20:03:49 <pjones> +1
20:03:51 <mclasen> +1
20:03:52 <smparrish> +1
20:03:52 <notting> sure, why not. +1
20:04:02 <nirik> #agreed 29th is fine for f12 EOL.
20:04:16 <nirik> #topic #418 Packager jgarzik violated Fedora Packaging (Review) Policy
20:04:17 <nirik> .fesco 418
20:04:18 <zodbot> nirik: #418 (Packager jgarzik violated Fedora Packaging (Review) Policy) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/418
20:04:18 <kylem> +1
20:04:43 <nirik> This is requesting censure of someone who closed merge reviews...
20:04:47 <pjones> I say we tar and feather him.
20:05:09 <notting> nirik: censure beyond the already-happened 'don't do that!'?
20:05:14 <nirik> I personally don't think censure is a good idea in this case. He's been educated...
20:05:41 <nirik> notting: yes, the ticket requests we "downgrade jgarzik's permissions in Red Hat Bugzilla for Fedora component"
20:06:10 <pjones> that's overkill.  he did something wrong, he's been told not to do it again.  let's not pull out the big guns unless he keeps doing it.
20:06:10 * notting votes -1 on the princple that there are other people that i would do that to well before we get to jgarzik
20:06:18 <pjones> notting: no kidding
20:06:36 <kylem> i'm just going to -1 right off the bat; this is ridiculous. if i could whine to fesco to nuke people's privs every time they annoyed me...
20:06:52 * pjones is -1 as well
20:06:54 <mjg59> I think his behaviour was unhelpful, his immediate action unfortunate and ideally we would educate people better
20:07:09 <smparrish> I would also say -1 on censure, he didn't know, he's been educated and it wont happen again
20:07:16 <mjg59> But if people who've been involved in the project for years don't know all of our policies I see that as our problem rather than their's
20:07:19 <nirik> right. -1 from me as well... is there some way we can communicate better to people moving forward?
20:07:23 <mjg59> And yeah, -1
20:07:35 <kylem> mjg59, agreed. he was certainly being a nuisance, but that's about it unless he repeats this in the future.
20:08:09 <nirik> I did update the wiki links to the cached review tracker thing thats much better than the raw reports he was looking at.
20:08:19 <nirik> and fired off a merge review discussion.
20:08:33 <mjg59> Yeah, that ought to help avoid this in future
20:08:34 <cwickert> I think many RH people need better education, but I don't think that jgarzik wanted to do something bad
20:08:42 <kylem> i was certainly extremely suprised to see traffic in my bugzilla folder about the kernel merge review. 8)
20:08:46 <mclasen> the merge reviews could probably do with an independent discussion
20:08:54 <cwickert> so -1 to any sanctions against jgarzik
20:09:22 <ajax> -1 to sanctioning jgarzik for all the reasons mentioned
20:09:27 <pjones> mclasen: indeed.
20:09:29 <nirik> mclasen: yeah.
20:09:54 <pjones> there's certainly a lot of sentiment from RH employees who have been maintaining these packages for some time that they're a giant waste of time.
20:09:55 <nirik> #agreed no sanctions at this time
20:10:32 <nirik> there's all kinds of issues with them... but thats no reason to close them IMHO.
20:10:49 <nirik> anyhow, we can have another discussion about them sometime.
20:10:51 <notting> i would say 'that's no reason to randomly and unilaterally close them without discussion'
20:11:11 <nirik> shall we move on to the pile-o-feature-fun(tm) now?
20:11:15 <mjg59> Sure
20:11:18 <notting> pjones: not sure they've been active enough to actually waste time
20:11:33 <pjones> notting: fair enough
20:11:36 <nirik> #topic #409 Feature Request: GNUstep
20:11:37 <nirik> .fesco 409
20:11:38 <zodbot> nirik: #409 (Feature Request: GNUstep) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/409
20:11:44 <nirik> we had some questions here. Did they get answered?
20:12:24 <nirik> https://fedoraproject.org/wiki/Talk:Features/GNUstep
20:13:10 <mjg59> gnustep-back isn't packaged
20:13:21 <notting> it's in review, iirc
20:13:34 <mjg59> Everything else in the list has been in Fedora since F10
20:13:34 <notting> 476056
20:14:14 <nirik> I thought I saw a few more too under review.
20:14:36 <nirik> oh, those were EL-6 branch requests.
20:14:42 <mjg59> Other than that, I think there's no benefit in mentioning Cocoa at all in the release note, but no objection otherwise
20:15:12 <cwickert> maybe we should give the feature owner another week to clarify?
20:15:28 <mjg59> I'll follow up
20:15:52 <nirik> ok. so defer again?
20:16:09 <mjg59> Yeah
20:16:16 <nirik> #agreed defer for another week for more info.
20:16:20 <nirik> #topic #413 F14Feature: http://fedoraproject.org/wiki/Features/Go_Programming
20:16:23 <nirik> .fesco 413
20:16:24 <zodbot> nirik: #413 (F14Feature: http://fedoraproject.org/wiki/Features/Go_Programming) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/413
20:16:25 <mjg59> Huh. Ok, the absence of gnustep-back seems to imply that gnustep can't actually *draw* anything under X right now
20:16:29 <nirik> we also had questions here.
20:16:32 <notting> mjg59: it was just approved
20:17:17 <nirik> I don't see any reply from the feature owner tho.
20:17:36 <nirik> would someone take the task to contact them over the next week and we can revisit this one again too?
20:17:48 <notting> well, he edited the feature page
20:17:56 <nirik> oh, I didn't see that...
20:17:59 <notting> and dropped gcc-go
20:18:34 <notting> at least, dropped it from 'scope'
20:18:41 <nirik> ah, ok.
20:18:59 <nirik> yeah, so with that scope are we ok with the feature?
20:19:37 * notting is ok. +1
20:19:47 <pjones> sure, why not? +1
20:19:49 * nirik is too... +1
20:19:56 <cwickert> ok, +1
20:19:58 <smparrish> works for me +1
20:19:59 <kylem> i'm fine with it. +1.
20:20:12 <mclasen> +1
20:20:15 <kylem> (really low impact to the rest of the distro, and it's kind of cool imho. :)
20:20:15 <nirik> #agreed This feature is approved
20:20:21 * cwickert thinks, we should also have some go packages, but anyway...
20:20:30 <nirik> #topic #419 F14Feature: DebugpythonStacks - http://fedoraproject.org/wiki/Features/DebugPythonStacks
20:20:30 <nirik> .fesco 419
20:20:31 <zodbot> nirik: #419 (F14Feature: DebugpythonStacks - http://fedoraproject.org/wiki/Features/DebugPythonStacks) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/419
20:20:39 <cwickert> strong +1
20:20:48 <pjones> very definitely +1
20:21:18 <notting> tl;dr. +1?
20:21:25 <nirik> +1 here as well... good work/news for people who are choosing a development platform. ;)
20:21:35 <smparrish> +1
20:21:47 <cwickert> notting: ?
20:22:10 <notting> cwickert: don't mind me. joking about the length of the feature page.
20:22:16 <ajax> niiice.  +1
20:22:16 <cwickert> ah
20:22:36 <nirik> #agreed This feature is approved
20:22:39 <mjg59> +1
20:22:43 <cwickert> notting: the feature page proves he is really working on it
20:22:53 <kylem> sounds good. +1.
20:23:08 <nirik> #topic #420 F14Feature: EC2 - http://fedoraproject.org/wiki/Features/EC2
20:23:08 <nirik> .fesco 420
20:23:09 <zodbot> nirik: #420 (F14Feature: EC2 - http://fedoraproject.org/wiki/Features/EC2) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/420
20:23:55 <notting> does this require pvgrub?
20:24:07 <jforbes> notting: Yes, but no
20:24:19 <ajax> the only thing that was sticky about this before was the requirement to use some non-free tool to publish the image.
20:24:20 <jforbes> notting: not required, but pvgrub is public now, so it will be used
20:24:21 <nirik> so, this would also be added to release criteria?
20:24:49 <jforbes> euca2ools is free and available already
20:25:03 <notting> jforbes: any concerns about weird compatiblity with whatever xen host ec2 is?
20:25:05 <nirik> also, might be nice to make sure we also retire old releases on EOL?
20:25:22 <ajax> i'm not sure what retiring them wins us
20:25:27 <kylem> notting, already dealt with. we had to ok a kernel patch because their xen is ancient.
20:25:38 <jforbes> notting: only concern has already been addressed with the kernel patch included in F13 and newer kernels
20:25:48 <nirik> ajax: a reduction in the number of people who come into #fedora and ask for help with a F8 ec2 image?
20:26:08 <notting> does retiring them from ec2 actively break people using them?
20:26:12 <jforbes> nirik: we have no control over the F8 images, which is why we are publishing them ourselves now
20:26:35 <mclasen> taking control certainly sounds like the right thing to do
20:26:47 <nirik> jforbes: yeah, just saying... if we push f14 at f14 release, can we eol/unpush it at f16+1month?
20:26:53 <jforbes> notting: not if they user persistant storage, but realistically people will probably make their own images based on ours
20:27:13 <nirik> anyhow, I guess thats a side topic.
20:27:18 <jforbes> nirik: we can, but that wont stop people who already copied it into their own
20:27:29 <nirik> +1 for this feature, it's something we should tout and is overdue. ;)
20:27:37 <nirik> jforbes: sure, understood.
20:27:52 <pjones> likewise, +1
20:27:57 <notting> +1
20:27:59 <smparrish> +1
20:28:03 <ajax> +1
20:28:05 <mclasen> +1 as well
20:28:07 <kylem> +1.
20:28:19 <kylem> thanks jforbes.
20:28:22 <nirik> #agreed This feature is approved
20:28:41 <nirik> #topic #421 F14Feature: Gdbindex - http://fedoraproject.org/wiki/Features/GdbIndex
20:28:41 <nirik> .fesco 421
20:28:42 <zodbot> nirik: #421 (F14Feature: Gdbindex - http://fedoraproject.org/wiki/Features/GdbIndex) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/421
20:29:24 <notting> oof
20:29:31 <notting> this looks like it requires a mass rebuild to be most useful
20:29:37 <nirik> is this going to affect our friend abrt?
20:29:50 <ajax> yeah, that's my only real beef with it.  i'm totally in favor of the feature itself though.
20:29:52 <mclasen> that was going to be my question: mass rebuild ?
20:29:53 <nirik> yeah, mass rebuild ugh.
20:30:00 <pjones> this sounds nice, but ugh.
20:30:06 <tromey> without a rebuild, it just means that things work like today
20:30:18 * cwickert thinkgs that only a feature with a mass rebuild is a good feature ;)
20:30:28 <ajax> we're starting to pile up a few things that "might be nicer" if there were a mass rebuild.
20:30:34 <nirik> yeah.
20:30:44 <ajax> let's consider the feature on its own merits, and then consider mass rebuild after feature freeze
20:30:49 <pjones> ajax: you're suggesting maybe we should get them all in and then do a rebuild?
20:30:50 * nirik nods.
20:31:06 * notting is +1 to the idea of the feature. faster gdb == good.
20:31:16 <nirik> I am +1 for this feature, it speeds things up and that sounds fine to me. ;)
20:31:19 <drago01> back to the old one mass rebuild per release ;)
20:31:31 <drago01> (yes isn't true but it felt like that for a while)
20:31:31 * cwickert doesn't care about a mass rebuild and likes a faster gdb, so +1
20:31:32 <mjg59> +1 I guess
20:31:33 <ajax> and this on its own is definitely +1 for me, gdb attaching to X takes entire _seconds_ and that's just lame.
20:31:47 <smparrish> +1 for faster debugging
20:32:23 <pjones> yeah, I'm definitely +1 on at least implementing it.
20:32:26 <nirik> #agreed This Feature is approved.
20:32:32 <nirik> thanks tromey
20:32:35 <kylem> should we side bar and discuss a rebuild? +1.
20:32:44 <ajax> kylem: not yet.
20:32:52 <tromey> thanks all, I'm going to push the gdb patches now :)
20:32:57 <nirik> kylem: I would say lets wait until our full feature list is done...
20:32:57 <ajax> GoldLinkerDefault is still relevant to that decision
20:33:05 <mclasen> do we need to ask rel-eng about scheduling a mass rebuild ?
20:33:06 <tromey> (upstream I mean)
20:33:08 * nirik notes we have more features for next week.
20:33:18 * mclasen has no idea how much preparation that requires
20:33:21 <kylem> fair.
20:33:31 <nirik> tromey: sounds good. ;) Might drop a heads up to the devel list too... in case there are any regressions?
20:33:42 <tromey> will do
20:33:51 <nirik> #topic #422 F14Feature: Gnome3 - http://fedoraproject.org/wiki/Features/Gnome3
20:33:52 <nirik> .fesco 422
20:33:53 <zodbot> nirik: #422 (F14Feature: Gnome3 - http://fedoraproject.org/wiki/Features/Gnome3) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/422
20:34:48 <nirik> can you manually choose to use 'gnome classic' ?
20:35:10 <nirik> even if your hardware works with gnome3?
20:35:21 <mclasen> details of fallback have not been worked out
20:35:22 <drago01> why would you want that?
20:35:26 <ajax> the desktop-effects capplet will still exist, i believe
20:35:36 <mclasen> but yes, I assume you will be able to configure a session with the panel and metacity
20:35:38 <ajax> fallback is a hard problem in general.
20:36:02 <nirik> well, I am not a gnome user, but I predict I will get a bunch of people asking about how to do that in #fedora who just don't like gnome-shell
20:36:05 <mclasen> and we might even ship a ready-made session for it
20:36:06 <drago01> well we do have some code for that (the your hardware/driver sucks nag in desktop-effects)
20:36:13 <ajax> but at least from the X side we'll try to make it so the compositor will refuse to start rather than hang.
20:36:15 <notting> nirik: 1) wait for automatic fallback in case of failure to be written 2) find the condition it uses 3) make that condition fail always on your system
20:37:11 <nirik> ok... just curious.
20:37:19 <drago01> notting: ...
20:37:37 <notting> drago01: not entirely serious.
20:37:38 <nirik> it would be nice if it was possible without pain and torment, IMHO...
20:38:05 <mclasen> any more questions on it ? things are a little in flux atm, with transition from gtk2 to gtk3, I hope that things stabilize a bit before the end of the week
20:38:38 * notting is in favor. +1
20:38:44 <cwickert> I would like a dialog: Do you want the new Gnome shell or the classic gnome desktop?
20:38:50 <drago01> no
20:38:52 <nirik> +1 here. This is the way upstream is going and people expect to see gnome3 soon. ;)
20:39:10 * nirik doesn't care if it's a setting or something, just that it be possible.
20:39:22 <ajax> +1 to acceptance.  fallback session seems like the reasonable approach.
20:39:23 <cwickert> ether way, +1
20:39:23 <drago01> a nag dialig is the wrong way to do it
20:39:24 <nirik> a dialog would confuse people who know nothing of the choices.
20:39:52 <pjones> I'm +1 , but I would really like some way to fall back.
20:40:43 <ajax> that's 5
20:40:50 <nirik> #agreed This Feature is approved.
20:40:53 * mclasen abstains
20:41:03 <nirik> #topic #423 F14Feature: GoldLinkerDefault - http://fedoraproject.org/wiki/Features/GoldLinkerDefault
20:41:03 <nirik> .fesco 423
20:41:04 <zodbot> nirik: #423 (F14Feature: GoldLinkerDefault - http://fedoraproject.org/wiki/Features/GoldLinkerDefault) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/423
20:41:23 <pjones> I just know this is going to break all my packages :)
20:42:03 <nirik> +1 for this, as I was expecting it in f13...
20:42:11 <ajax> given the ld.bfd escape hatch, i'm fine with this.
20:42:14 <nirik> as for mass rebuild, this is another 'nice to mass rebuild for' right?
20:42:20 <pjones> ajax: yeah.
20:42:23 <mjg59> Yeah
20:42:32 <pjones> "for everything except glibc and the kernel" seems a bit short-sighted, but it's also not a real requirement.
20:42:33 <ajax> do we still have the list from f13 of everything that ftbfs'd with --no-add-needed?
20:42:33 * mclasen had 2 questions on this
20:42:41 <mclasen> 1. will we drop prelink at the same time ?
20:42:43 <nirik> perhaps we could get the items that would be nice to mass rebuild for in, and then get mdomsch to run a mass rebuild test?
20:42:45 <notting> why does the kernel and glibc need to still use the old one?
20:42:51 <mclasen> 2. why can't glibs and kernel use gold ?
20:43:00 <ajax> notting: gold linker script support isn't quite as macho as binutils'
20:43:09 <nirik> ajax: yeah, there is a blocker bug still... not sure how much is still on it.
20:43:18 <ajax> which is also why it's going to break all of pjones' packages
20:43:18 <drago01> 1. huh? does it affect runtime linking at all?
20:43:32 <ajax> grub has fun linker scripts too
20:43:36 <ajax> but most things do not
20:43:37 <drago01> (as in in a noticeable way)
20:43:37 <pjones> as does gnu-efi
20:43:41 <mclasen> there's a bug reference somewhere from the feature page that states that gold and prelink are incompatible
20:44:39 <nirik> bonus for going with gold! ;)
20:44:54 <mclasen> http://sourceware.org/bugzilla/show_bug.cgi?id=11805 is the prelink issue
20:45:24 <drago01> there is a patch somewhere http://sourceware.org/bugzilla/attachment.cgi?id=4713&action=view ( not sure how correct it is or wheter it has been merged)
20:45:26 <nirik> opened just 2 days ago
20:45:38 <drago01> answers my question
20:45:54 <notting> we'd obviously need that fixed. or we drop prelink
20:46:06 <ajax> looks like prelink just fails until that's fixed though.
20:46:16 <ajax> not that it destroys data
20:46:25 * nirik isn't sure prelink is worth it anymore, but we have had that discussion before I think.
20:46:35 <ajax> you and everybody else.
20:46:36 <mclasen> just trying to clarify if 'drop prelink' is within the scope of the feature
20:46:51 <drago01> nim-nim: and no one bothered to provide numbers (in either direction)
20:46:52 <nirik> well, we could defer and ask that specifically?
20:47:00 <drago01> err
20:47:02 <drago01> nirik: ^^
20:47:08 <drago01> nim-nim: sorry tab fail
20:47:15 <nirik> drago01: prelink also causes fun things like local firefox builds to fail. ;)
20:47:54 <drago01> nirik: you need a faster builder to avoid that :P
20:47:55 <nirik> anyhow? defer and ask for clarification? or vote today?
20:48:11 <mclasen> I put the question on the discussion page
20:48:22 <ajax> defer i think
20:48:24 <mclasen> I thought
20:48:25 <notting> we can defer
20:48:44 <nirik> ok.
20:48:52 <nirik> #agreed defer and ask for more info on this feature.
20:49:08 <nirik> #topic #424 F14Feature: netbeans 6.9 - http://fedoraproject.org/wiki/Features/NetBeans_6.9
20:49:08 <nirik> .fesco 424
20:49:09 <zodbot> nirik: #424 (F14Feature: netbeans 6.9 - http://fedoraproject.org/wiki/Features/NetBeans_6.9) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/424
20:49:13 <nirik> another fedora, another netbeans. ;)
20:49:30 <notting> at what point do we start drawing a line in the sand here? or is it too late?
20:49:49 <ajax> netwho?
20:49:53 <nirik> it might be too late, since we approved all the others.
20:50:35 <notting> 'See also: Netbeans on the twitter.com'
20:50:57 <nirik> see the NetBeans_6.8 and NetBeans_6.7 and NetBeans_6.5 and NetBeans_6.1 features.
20:50:58 <drago01> so we get a netbeans feature per release? ;)
20:51:04 <nirik> drago01: seems so
20:51:18 <drago01> not sure that it is a bad thing though
20:51:18 <ajax> wow, javafx still exists
20:51:24 <pjones> #  Percentage of completion: 40%
20:51:37 <drago01> ajax: with almost no users if any...
20:51:39 <notting> pjones: well upstream is released. apparently there are some package reviews
20:51:47 <nirik> well, we always approved them before on the basis of being good press to note...
20:52:42 <pjones> sure, why not.
20:52:47 <nirik> so, on that basis, weak +1 here...
20:53:05 * mclasen thinks it is good to have outside interest in Fedora features like this
20:53:11 <mclasen> +1 from me
20:53:13 <smparrish> +1 for the press
20:53:14 <ajax> +1 why not
20:53:19 <pjones> I'm +1, but mostly just bored.
20:53:26 <cwickert> +1
20:53:30 <notting> +1, then.
20:53:31 <nirik> #agreed This Feature is approved.
20:53:41 <nirik> #topic #425 F14Feature: OpenSCAP - http://fedoraproject.org/wiki/Features/OpenSCAP
20:53:41 <nirik> .fesco 425
20:53:42 <zodbot> nirik: #425 (F14Feature: OpenSCAP - http://fedoraproject.org/wiki/Features/OpenSCAP) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/425
20:54:41 <pjones> hey, acronym land.
20:54:48 <ajax> that's how you know it's secure
20:55:31 <sgrubb> I can talk about this feature if you want any discussion
20:55:31 <pjones> I don't know any reason not to +1 this.
20:55:36 <notting> i'm worried about the % done, but there's nothing bad in the feature itself. +1
20:55:44 <nirik> +1 here...
20:55:50 <smparrish> +1 as well
20:55:59 <pvrabec> there will be new release tomorrow and I will update % done
20:56:22 <ajax> +1, needed for building the tools to actually do this if nothing else
20:56:34 <nirik> #agreed This Feature is approved.
20:56:38 <kylem> +1, but these things are getting tedious. one feature per child.
20:56:39 <mjg59> +1
20:56:43 <kylem> s/child/package/
20:56:47 <nirik> thanks pvrabec / sgrubb. :)
20:56:56 <nirik> #topic #426 F14Feature: Rakudo Star - http://fedoraproject.org/wiki/Features/Rakudo_Star
20:56:56 <nirik> .fesco 426
20:56:57 <zodbot> nirik: #426 (F14Feature: Rakudo Star - http://fedoraproject.org/wiki/Features/Rakudo_Star) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/426
20:57:24 <ajax> isn't that an anime?
20:57:31 <kylem> perl 6.
20:57:37 <nirik> same thing. ;)
20:58:12 <notting> ajax: i thought it was what video killed.
20:58:30 <nirik> cwickert: so, how is this different than what we have now?
20:58:39 <nirik> or this is just a update to a production release?
20:58:42 <drago01> isn't perl 6 supposed to be vaporware?
20:59:03 <cwickert> it is a production release of rakudo, right
20:59:08 <ajax> why is this perl6 better than the others?  how do we choose one?
20:59:25 <nirik> ajax: it's the only one that exists so far?
20:59:38 <cwickert> it is the most active one and the one that implements that most of the perl 6 specs
20:59:38 <notting> so, this is 1.0, and therefore better than the prior version of this feature, which was 0.<something>? (essentially)
20:59:43 <nirik> official perl doesn't have a v6 release does it?
20:59:44 <drago01> we have multiple interpreters for different languages too
20:59:49 <ajax> nirik: "There are currently multiple implementation projects of Perl 6 underway, the most actively developed one is Rakudo, which is based on the Parrot virtual machine."
20:59:58 <pjones> so the question is, if another one comes along that's more widely accepted (like an official perl release...), are we going to regret this?
21:00:01 <drago01> nirik: that's the vaporware part
21:00:25 * nirik doesn't see why we would... we could always drop it, or let the "better" one obsolete it or something...
21:00:39 <nirik> or let them be parallel installable and let users choose?
21:00:55 <cwickert> pjones: there is nothing on the horizon, rakudo is likely to become *the* perl 6
21:00:59 * nirik notes it's already in fedora... it was a f13 feature.
21:01:03 * notting is tentatively +1 for touting this as the 'production/1.0/etc' verson. not so sure about having this being an 'every release we have new XXX' feature
21:01:11 <pjones> eh, sure then, +1
21:01:22 <cwickert> and the reason why it is a feature is that there are changes to the current rakudo
21:01:22 <ajax> +1, despite it being perl.
21:01:34 <cwickert> it will no longer require parrot but will be standalone
21:01:34 <nirik> +1 here too
21:01:38 <smparrish> +1
21:01:39 <cwickert> +1
21:01:43 <mjg59> +1
21:01:46 <nirik> #agreed Feature is approved.
21:01:58 <nirik> #topic #427 F14Feature: Spice - http://fedoraproject.org/wiki/Features/Spice
21:01:58 <nirik> .fesco 427
21:01:59 <cwickert> for the record: the feature owner also is the release manager
21:02:00 <zodbot> nirik: #427 (F14Feature: Spice - http://fedoraproject.org/wiki/Features/Spice) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/427
21:02:56 <nirik> sad trombone on the lack of libvirt support.
21:03:18 <mclasen> it is not going to be super-polished and impressive in f14
21:03:19 <pjones> I like the scarequoted '"hardware"'
21:03:22 <jforbes> Gotta start somewhere
21:03:26 <mclasen> that will come later
21:03:34 <notting> i can't help but notice '#  Spice support needs to be added to the Fedora qemu package '
21:03:46 <notting> which sounds like a fairly large task for a short sentence
21:03:51 <pjones> mclasen: then what's the point of it being an F14 feature rather than something nicer and shinier in F15?
21:03:53 <mclasen> qemu package maintainers have agreed to carry the patch, afaik
21:03:55 <nirik> +1 anyhow, but even basic libvirt support would be nice, IMHO.
21:03:56 <ajax> qemu upstream is... not especially great at release schedules.
21:04:00 <ajax> notting: ^
21:04:03 <jforbes> notting: that is pending the 0.13 update.  It isn't exactly out of the blue
21:04:19 <mclasen> pjones: if we make it an f15 feature, you'll say 'old hat, was in f14 already'...
21:04:22 <jforbes> notting: We will have 0.13 before feature freeze
21:04:42 <notting> no alexl
21:04:50 <notting> how are we planning on handling the 'windows drivers' bullet point?
21:04:59 <mclasen> alexl: is on vacation, and then on parental leave...
21:05:04 <pjones> mclasen: somebody might, but it won't be me.
21:05:12 <jforbes> notting: I expect the same way we are handling virtio-win now
21:05:19 <jforbes> alt.fedoraproject.org
21:06:11 <notting> mclasen: who's the lucky inheritee?
21:06:48 <jforbes> notting: there are a few people working on it
21:07:27 <nirik> so, votes ? or more info/defer ? or ?
21:07:48 * notting is +1
21:08:00 <ajax> +1
21:08:05 <smparrish> +1
21:08:11 <kylem> +1, cool beans.
21:08:15 <pjones> I guess I'm okay with it, though it seems like we're going to want to put it in relnotes /again/ next release.
21:08:18 <pjones> but meh, +1
21:08:32 <nirik> #agreed This Feature is approved.
21:08:40 <nirik> #topic FES tickets roundup.
21:08:45 <nirik> thanks for the info jforbes
21:08:48 <nirik> mmcgrath: you around?
21:08:51 <drago01> pjones: we could name it "libvirt support for spice"
21:09:01 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
21:09:25 <nirik> mmcgrath finished a ticket there this morning. We now have: http://meetbot.fedoraproject.org/teams/
21:09:43 <mclasen> notting: not sure how they've organized that, but kraxel seems to be doing the other packages now
21:09:45 <nirik> so all the meetings with the same meetingname should show up in the same dir.
21:09:52 <ajax> niiice
21:10:11 <pjones> yeah, that looked pretty nice when I looked at it earlier.
21:10:22 <mmcgrath> hey
21:10:41 <mmcgrath> So really the big workings this week on my end were getting the /teams/ setup
21:10:41 <notting> slick
21:11:03 <mmcgrath> and getting more rawhide broken deps.
21:11:17 <mmcgrath> Actually rawhide's broken deps are in OK shape but there's two packages right nwo that won't build blocking several others from building
21:11:18 <nirik> mmcgrath: so do we have enough tickets for the people we have? do we need more tickets or people?
21:11:53 <mmcgrath> more people.
21:11:56 <mmcgrath> well, here's the roundup on people.
21:12:12 <mmcgrath> we've had a high turnover rate (to be expected) but in the ones that turned over, many of them didn't actually do anything.
21:12:36 <mmcgrath> it was one of those "follow up" "sure, I'll get right on it" "follow up" "sorry was busy last week but have time this week" "follow up" type thing.
21:12:39 <mmcgrath> where no actual work got done.
21:12:57 <mmcgrath> but the people that have done work, they've generally been great at it.  Bruno and Jose both come to mind immediately
21:13:03 <mmcgrath> but Bruno's been busy with spin stuff lately.
21:13:20 <mmcgrath> anyway, end of the day we need more dedicated people.  I might send another cattle call out this week to devel and see who turns up
21:13:22 <nirik> so, perhaps we should tell those folks who don't have time to try again later and reassign/get new people involved?
21:13:29 * nirik nods.
21:13:41 <mmcgrath> nirik: yeah that's what I've been doing.
21:13:55 <mmcgrath> after a couple of weeks I just ask if they'd like me to remove the FES resume tag for now until they get more time.
21:13:57 <nirik> if you like I can probibly dream up some more easy tickets that just need someone doing them. ;) Perhaps other fesco folks can do likewise.
21:14:21 <nirik> Thanks for the info mmcgrath.
21:14:25 <mmcgrath> A wider range of tickes might be good just because we've had some people show up that are clueless about packaging and lots of the tasks have been packaging oriented.
21:14:29 <mmcgrath> yup yup, that's all I've got
21:14:32 <nirik> #topic Open Floor
21:14:38 * gholms raises hand
21:14:44 <nirik> ok, we have about 4-5 more features for next week, BTW.
21:14:48 <nirik> gholms: go ahead.
21:15:09 <gholms> (I was absent for the EC2 discussion, so a question on that)
21:16:15 <nirik> fire away.
21:16:44 <gholms> To build pvgrub images for EC2 one needs a "block device mapping" feature, which isn't supported in the latest stable version of euca2ools in the repos.  Upstream claims to support it in the latest dev builds, but that requires a prerelease python-boto.  (...)
21:17:34 <nirik> jforbes: you still around? can you address that?
21:17:47 <gholms> Though I haven't done much thorough testing, this means that we can either build Fedora images using either prerelease euca2ools and prerelease python-boto or we use ec2-ami-tools frpm rpmfusion-nonfree.
21:18:26 <nirik> I think it needs to be prerelease, we can't use rpmfusion stuff in our process.
21:18:28 <gholms> Any recommendations?  Both euca2ools and python-boto are in our repos, just not new enough, and I'm hesitant to recommend throwing cvs copies into production.
21:18:30 <jforbes> gholms: read cloud list :) python-boto is pusing towards release
21:18:44 <gholms> jforbes: Ooh, will do.
21:18:45 <rsc> ah...python-boto!
21:18:54 <jforbes> gholms: oh, you were the one who said it
21:18:58 <nirik> Anything else for open floor?
21:19:03 * gholms raises hand... again
21:19:20 <pjones> so the plan is to have newer python-boto then?
21:19:24 <rsc> is anybody here in touch with python-boto folks?
21:19:39 <rsc> because I _will_ _not_ update python-boto to an alpha release...
21:19:49 <nirik> gholms: ask away. ;)
21:19:52 <rsc> upstream is non-responsive to me...
21:19:56 * nirik has no idea on python-boto.
21:19:58 <jforbes> pjones: That would be the plan for euca2ools, but not a requirement for the EC2 feature anyway
21:20:29 <gholms> Since one needs F13 + updates to install on the XO, do we need new install images?
21:21:15 <gholms> So do we use a temporary repo for building EC2 images until python-boto releases again?
21:21:30 <gholms> I'm looking for recommendations, mostly.  We can discuss this in detail on the cloud list.
21:21:35 <ajax> gholms: we don't respin install images.  unity does though.
21:21:56 <jforbes> gholms: if we want to, though I am not using euca2ools on the F13 images anyway.
21:23:06 * nirik suggests further discussion on cloud list, as I am not up on what python-boto or these tools do/are used for.
21:24:10 <nirik> any other items for open floor? or shall we stick a fork in this meeting?
21:24:52 <ajax> i got nothin'
21:24:58 * gholms hands nirik a fork
21:25:14 <nirik> Thanks for coming everyone... and sitting though another long meeting. ;)
21:25:21 <nirik> #endmeeting