19:00:01 <nirik> #startmeeting FESCO (2010-05-25)
19:00:01 <zodbot> Meeting started Tue May 25 19:00:01 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:01 <nirik> #meetingname fesco
19:00:01 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
19:00:01 <nirik> #topic init process
19:00:01 <zodbot> The meeting name has been set to 'fesco'
19:00:01 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
19:00:07 * skvidal is here
19:00:12 <ajax> hereish.
19:00:17 * pjones is here also, but not where skvidal is.
19:00:37 <nirik> cwickert had to step away for a bit, and sends his regrets.
19:00:39 <mjg59> Here
19:00:42 <skvidal> pjones: but I bet you wish you were - durham being as cool as it is
19:00:52 <skvidal> nirik: I bet he didn't send all that many regrets
19:00:58 <pjones> oh yeah, durham is awesome.
19:01:05 * notting is here
19:01:12 <Kevin_Kofler> Present.
19:01:22 <nirik> ok, lets go ahead and dive in...
19:01:24 <pjones> I recall the years I worked in durham, surrounded by the EPA.  Great time.
19:01:31 * dgilmore 
19:01:33 <nirik> #topic #340 #Determine and approve F11 end of life date
19:01:33 <nirik> .fesco 340
19:01:37 <zodbot> nirik: #340 (Determine and approve F11 end of life date) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/340
19:01:41 <nirik> The ticket that keeps on giving. ;)
19:01:58 <nirik> f13 pushed out a week with it's slip.
19:01:59 <Kevin_Kofler> +1 to slipping it another week to match the final F13 release slip.
19:01:59 * dgilmore says leave it as is but doesnt care if we extend it
19:02:04 <nirik> do we want to push f11 eol out more too?
19:02:46 <nirik> I'm ok with pushing it out as well... doesn't matter too much, but we should provide it the +1month
19:03:09 * notting is ok with making it match the final release date.
19:03:24 * skvidal is fine with it, too
19:03:25 <mjg59> Yes, I'm +1 to slipping it one more week
19:03:32 <ajax> +1 slip
19:03:45 <nirik> #agreed new f11 eol date is 2010-06-25
19:04:00 <pjones> +1 to slip
19:04:14 <nirik> ok, lets discuss the yelp thing next, and save the updates doom for last.
19:04:17 <nirik> #topic #381 #yelp dependency of gnome desktop apps
19:04:17 <nirik> .fesco 381
19:04:18 <zodbot> nirik: #381 (yelp dependency of gnome desktop apps) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/381
19:04:43 <Kevin_Kofler> Basically, it's impossible to fit yelp and its dependencies on the KDE Live CD.
19:04:44 <nirik> so, the two alternatives here are: yelp deps so help works in all the apps that use it, or no deps to avoid bloat
19:04:53 <Kevin_Kofler> Even if it switches to webkitgtk, that won't be of much help to us.
19:05:09 <Kevin_Kofler> So all the stuff which is dragged onto the KDE spin CANNOT require yelp.
19:05:15 <Kevin_Kofler> It's just technically not possible.
19:05:15 * nirik nods.
19:05:22 <dgilmore> can the functionality yelp provides be done generically that it will work with whatever browser is installed
19:05:27 <dgilmore> say via alternatives
19:05:30 <notting> dgilmore: it's based off a gconf key
19:05:31 <dgilmore> or something like that
19:05:42 <dgilmore> notting: ewww
19:06:03 <Kevin_Kofler> Yelp docs don't work in any other viewer.
19:06:14 <nirik> I don't mind the offering to install it when you select help, but thats not implemented.
19:06:19 <Kevin_Kofler> They're docbook-based just like KDE's help format, but they use docbook differently. :-(
19:06:23 <Kevin_Kofler> So they're not compaitble.
19:06:27 <Kevin_Kofler> *compatible
19:06:46 <nirik> bummer. ;(
19:06:50 <mjg59> The desirable solution is for there to be packagekit integration for this
19:06:56 <nirik> mjg59: +1.
19:07:02 <mjg59> And then include it in the relevant comps
19:07:10 <nirik> in the mean time I think we should just say not to add the dep...
19:07:24 <Kevin_Kofler> Assuming it'll actually work with KPackageKit, I can agree with that.
19:07:25 <notting> mjg59: ... whyt? is it really a better experience for people "click here to install a help browser"
19:07:37 <pjones> mjg59: absolutely
19:07:46 <dgilmore> best experience is that it just works
19:07:47 <mjg59> notting: No, so it should be part of the default install on the gnome spin
19:07:51 <Kevin_Kofler> The ideal solution would be for khelpcenter to support yelp docs.
19:07:58 <pjones> notting: no, but "you clicked on help, install the help system" might be kindof okay.
19:08:01 <Kevin_Kofler> And for GNOME apps to be able to fire up khelpcenter under KDE.
19:08:03 <dgilmore> but i dont know how we could make it generic to work everywhere
19:08:09 <Kevin_Kofler> But it's not something we can easily add.
19:08:11 <notting> gnome-vfs2 sets the help broswer gconf key, so it could require it
19:08:26 <notting> but that only helps apps that use libgnome/libgnomeui. which there aren't that many of these days
19:09:01 <Kevin_Kofler> notting: Anything that drags yelp onto the KDE spin through indirect deps is not helpful. :-(
19:09:07 <mjg59> If it's part of the default install on the desktop spin, then right now the bad UI experience is likely to be limited to KDE
19:09:17 <Kevin_Kofler> Sadly, a lot of gnomish stuff is dragged in by Anaconda.
19:09:17 <nirik> mjg59: and lxde and xfce, etc. ;)
19:09:27 <mjg59> And while it'd be nice for it to work on KDE, it's clear that that's not currently possible
19:09:31 <notting> apps with completely non-functional help aren't a good thing to have either
19:09:35 <mjg59> nirik: Well, xfce should be ok
19:09:51 <nirik> the xfce spin doesn't have yelp on it I don't think
19:09:53 <mjg59> notting: The yelp dependency chain is sufficiently large that imposing it on the KDE spin clearly isn't practical
19:09:58 <dgilmore> what about LXDE?
19:10:13 * nirik goes to look.
19:10:30 <mjg59> notting: Improving user experience at the cost of KDE not being able to ship on a CD doesn't seem like a net win
19:10:43 <nirik> no yelp on lxde either.
19:10:46 <notting> gtk, xslt, xml2, rarian, gecko. i'm assuming it's the gecko-libs that's the complaint?
19:11:05 <Kevin_Kofler> rarian is also an extraneous dep.
19:11:18 <Kevin_Kofler> And after replacing gecko-libs with webkitgtk, webkitgtk will be the problem.
19:11:27 <Kevin_Kofler> Those things are quite large and have many deps.
19:11:33 <notting> rarian is 300k with no additional deps
19:11:35 <skvidal> here's the dep tree
19:11:36 <skvidal> http://fpaste.org/406j/
19:12:02 <Kevin_Kofler> We're already under very tight size constraints.
19:12:17 <notting> do you ship firefox?
19:12:21 <Kevin_Kofler> No.
19:12:33 <Kevin_Kofler> I think none of the non-GNOME spins does.
19:12:43 <nirik> perhaps short term we could make a 'yelp-warning' or something that provides a yelp that just points to a doc/info and asks the user to install yelp?
19:12:48 <nirik> (or is that too complex/crazy)
19:12:57 <mjg59> nirik: Hm. That might work.
19:12:57 <nirik> Xfce does ship firefox.
19:13:12 <Kevin_Kofler> For example, we had to stop shipping separate fonts for Chinese, Japanese and Korean, instead shipping one minimal CJK font, on the KDE live CD because there was just no room.
19:13:35 <Kevin_Kofler> (FWIW, I hope we can get LZMA live image support into F14, that'd help!)
19:13:49 <pjones> (FWIW, patches welcome.)
19:14:08 <nirik> so, where do we go here?
19:14:37 <mjg59> Ok. How about we discuss the nirik's plan with the yelp maintainer, with a long-term aim of either integrating PK support or (long term) tools that can handle both doc formats?
19:14:45 <ajax> i kinda like the yelp-warning idea
19:14:54 <nirik> .whoowns yelp
19:14:54 <zodbot> nirik: mbarnes
19:14:57 <skvidal> ajax: can we call it yelp-yelp!?
19:15:01 <skvidal> b/c that amuses me
19:15:20 <nirik> ha
19:15:20 <ajax> yelp-yourself
19:15:36 <nirik> ok, would anyone like to lead that effort? pretty please? :)
19:15:43 <mjg59> Sure
19:15:49 <nirik> do we suggest for now that we don't add the deps?
19:15:58 <nirik> mjg59: excellent. Thanks.
19:16:04 <mjg59> I think so for the immediate short-term
19:16:20 <pjones> well, I think it's clear we can't add all the deps for practical reasons
19:16:27 <mjg59> Not currently, at least
19:16:30 <nirik> #action mjg59 will talk to yelp maintainer(s) and see about PK integration and/or a yelp-yelp stub package
19:16:42 <nirik> anyone object to that ? or should we vote on it?
19:16:52 <Kevin_Kofler> But don't the apps already say something similar to what the stub would say?
19:17:05 <notting> depends on the app
19:17:09 <Kevin_Kofler> I'm not sure it's really worth the effort to have a dummy yelp.
19:17:40 <notting> the libgnome help api might have a warning, but apps that just hook up gtk_uri_show("ghelp://") would have to catch the error themselves
19:18:21 <nirik> well, I guess we could leave that to how the maintainer(s) want to move forward?
19:18:32 <nirik> ie, change the api, or provide a stub, or whatever.
19:18:47 <nirik> as long as in the end it tells the user what they need to do, or offers to do it for them?
19:19:22 <mjg59> Yeah
19:19:47 <nirik> proposal: recommend currently NOT to add yelp dependencies. Will work on longer term/better solution from here.
19:20:36 <ajax> +1 nirik
19:20:51 <pjones> I'm +1 on that.
19:20:55 <Kevin_Kofler> +1
19:21:00 <mjg59> +1
19:21:05 <nirik> +1 for my own proposal obviously.
19:21:26 <notting> +1. altough does this imply a similar plan to *remove* existing ones?
19:21:40 <pjones> no.
19:21:49 <notting> ok.
19:21:51 <nirik> #agreed recommend currently NOT to add yelp dependencies. Will work on longer term/better solution from here.
19:21:54 <pjones> if we find we need to do that, it should be handled separately.
19:22:19 <nirik> no, I wouldn't think so... up to the maintainters, if there is some real need.
19:22:31 <nirik> ok, moving along...
19:22:34 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:22:35 <nirik> .fesco 351
19:22:36 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:22:57 <nirik> I'd like to start off by saying there is now a seperate ticket for the Board vision and implementation.
19:23:12 <nirik> please direct comments about the board vision to the board and/or the ticket.
19:23:55 <nirik> so, on implementation:
19:24:09 <nirik> - AutoQA is not ready yet... there is some updates on that in the ticket.
19:24:47 <nirik> - On the critical path section
19:25:04 <nirik> we need to get bodhi using the critical path we have setup.
19:25:20 <nirik> we need to get proventesters more setup.
19:25:49 <nirik> One thing to note here. In the runup to f13, we were using the critical path with approvals for updates.
19:26:02 <nirik> Now that f13 is released, we are no longer doing so, which seems a bit strange.
19:26:23 <Kevin_Kofler> Yet it makes sense because this process was for preparing a release, not updates.
19:26:58 <nirik> it seems odd to me from the standpoint of: we are very carefull and want a good stable release, but once it's released we no longer care. Which is not what I would want.
19:27:04 <notting> nirik: lmacken was looking at wiring up the critical path import into pkgdb some last week
19:27:23 <ajax> nirik: it is strange, yes.
19:27:45 <nirik> notting: yeah. Not sure an eta on that, but I can try and find out
19:27:58 <Kevin_Kofler> It makes sense from the standpoint of: We want our live images to work and our release to be installable, but issues in updates can usually be fixed by another update, or by downgrading to the GA version.
19:28:42 <nirik> - On the "Other updates" section of the policy
19:28:47 <Kevin_Kofler> Of course fixing the issue in another update is going to be less effective due to the very proposal being discussed, which bans direct stable pushes except if sufficient karma is given.
19:28:59 <nirik> I filed some bodhi tickets on them... we need those ready before implementation.
19:29:33 <nirik> So, thats what I know of implementation. I can try and get some concrete dates/times for things next week.
19:30:00 <nirik> Does anyone have anything to add? Or anything they would like to help with? :)
19:30:41 <notting> nirik: technically, critical path was part of NFR, and the F13 implementation was based on that, not this new policy
19:30:49 <nirik> notting: right.
19:31:03 <nirik> but we are re-using the critical path stuff for our updates policy.
19:31:08 <nirik> (when we have it in place)
19:31:18 <notting> so, whether we have critpath verification on for f13 post-GA is a separate issue from the updates policy
19:31:46 <Kevin_Kofler> F13 post-GA should use the updates policy when it's ready, and nothing now, not the critical path policy which was never intended to be used on post-GA.
19:32:14 <nirik> notting: yeah, I suppose so.
19:32:37 <nirik> Oh, one other thing: If parts are ready before others, should we implement them as they become available?
19:32:46 <Kevin_Kofler> No.
19:32:58 <nirik> ie, if AutoQA isn't ready yet, should we put critical path and other packages in place if they are.
19:33:06 <ajax> there's probably an order that makes sense
19:33:11 <ajax> and some orders that don't
19:33:12 <Kevin_Kofler> The policy needs to be implemented all at once or not at all.
19:33:19 <ajax> we'll burn those bridges when we get to them
19:33:25 <nirik> ok, fair enough.
19:33:27 <skvidal> nirik: I think some of the items can come in piecemeal
19:33:32 * nirik does too.
19:33:39 <notting> what do you mean by implement them? autoqa can be running independent of rule-based application of the results
19:33:42 <nirik> but since we don't have any ready, it's probibly moot.
19:33:51 <Kevin_Kofler> AutoQA is the most important part, before that's implemented, we shouldn't do anything else.
19:34:06 <nirik> notting: I mean if we have critical path all ready, but nothing else, should we land it in bodhi, announce it, etc.
19:34:21 <Kevin_Kofler> It's really confusing for maintainers if we do things piecemeal.
19:34:36 <nirik> Kevin_Kofler: I think they are largely independent personally. All are good, but any is better than none.
19:35:05 <nirik> well, since we have nothing ready, it's moot. ;)
19:35:21 <nirik> Anything else on this topic? will move on in a few.
19:35:34 <skvidal> I suspect in the not-so-distant future pkgers will be able to optin to autoqa test results
19:35:37 <skvidal> following a koji build
19:35:46 <nirik> skvidal: excellent.
19:35:56 <nirik> #topic Elections
19:35:58 <notting> do we want to actually take a vote on whether to have current no-frozen-rawhide critpath criteria applied to f-13 GA?
19:35:59 <skvidal> so they'll get an eamil about things that rpmguard/rpmlint has found wrong/odd/questionable about their pkgs
19:36:04 <nirik> #undor
19:36:06 <nirik> #undo
19:36:06 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x22d499d0>
19:36:19 <nirik> notting: we could if you like...
19:36:22 <ajax> thanks python.
19:36:36 <pjones> somebody didn't def __str__().
19:36:41 <Kevin_Kofler> -1 to that, NFR critpath is not intended for releases.
19:36:55 <Kevin_Kofler> (i.e. updates)
19:37:06 <skvidal> notting: do you want to have a vote?
19:37:16 <nirik> notting: we also have a small pool of people in proventesters right now, which could slow things down.
19:37:23 <nirik> .members proventesters
19:37:24 <zodbot> nirik: Members of proventesters: adamwill jkeating @jlaska johannbg kparal liam lmacken @maxamillion notting rhe wwoods
19:37:48 * nirik waits for all the qa people coming out of the woodwork when they see their nick highlighted.
19:38:03 <notting> skvidal: given the tickets nirik filed against bodhi, it would be best to clarify whether it's "we want this now, fix and deploy" or "we want this available at some future point"
19:38:13 * Kevin_Kofler nominates rdieter for proventesters.
19:38:28 <nirik> Kevin_Kofler: have him add a ticket to the qa trac on it. Thats what I did.
19:38:50 <Kevin_Kofler> OK, will do.
19:39:12 <notting> skvidal: but if no one is speaking up in favor of it, we can take that as tacit disapproval and move on
19:39:23 <skvidal> notting: I'd be happy to speak in favor of it
19:39:38 <skvidal> notting: +1 to having the critpath rules enforced in f13 and updates
19:39:44 <nirik> notting: I am open to the idea... I think it might not be a bad one. Not sure if we should get QA folks buyin on it before agreeing on it tho
19:39:57 <jlaska> nirik: Hey there, what's up?
19:40:01 <Kevin_Kofler> In case you missed it: <Kevin_Kofler> -1 to that, NFR critpath is not intended for releases.
19:40:07 <Kevin_Kofler> <Kevin_Kofler> (i.e. updates)
19:40:21 <nirik> jlaska: so, on f13... we used critical path/NFR on the rollup to release.
19:40:30 <nirik> jlaska: now that it's released, we aren't.
19:40:42 <nirik> should we consider doing so for the release? or do you think thats a bad idea?
19:40:52 <ajax> i really don't think turning critpath _off_ for updates makes any sense
19:41:06 <pjones> yeah, I'm thinking the same criteria should continue to apply
19:41:12 <Kevin_Kofler> It makes sense because it was designed as a tool for pre-release freezes, NOT updates.
19:41:12 <ajax> i mean, otherwise, why have releases.
19:41:28 <Kevin_Kofler> To have something which installs and has a working live image.
19:41:36 <ajax> i don't agree with that theory.  i think it was designed as a tool for creating working systems.
19:41:39 <Kevin_Kofler> Bugs in updates can usually be fixed by another update.
19:41:42 <jlaska> perhaps it wasn't clearly stated, but I was under the impression critpath would continue for the life of a release (from branched to EOL)
19:41:54 <ajax> if we're going to create a working stable point and then break it after, why bother.
19:41:55 <nirik> jlaska: that seems to have not been what happened. ;)
19:42:19 <Kevin_Kofler> Then why was this explicitly written into the update policy in the first place?
19:42:33 <Kevin_Kofler> I was under the clear impression this was a NEW thing in the update policy.
19:42:45 <nirik> Kevin_Kofler: it was unclear from what I saw.
19:42:45 <jlaska> nirik: so I'd be in favor of continuing this.  Seems odd to stop it, for reasons already noted above
19:42:48 <Kevin_Kofler> Critpath has always been about freezes.
19:42:50 <nirik> it didn't say one way or another.
19:42:52 <skvidal> ajax: and updates is even more important - the critpath pkgs keep you ABLE to update so you can't be updating them w/o proper testing
19:43:15 <ajax> skvidal: right.
19:43:19 <nirik> ok, so we are +1 / -1 so far, more votes?
19:43:25 <skvidal> who is -1?
19:43:30 <pjones> skvidal: kk
19:43:33 <skvidal> ah
19:43:33 <nirik> skvidal: Kevin_Kofler is.
19:43:39 <ajax> what am i voting on again?  critpath rules for updates too?
19:43:47 <Kevin_Kofler> ajax: Yes.
19:43:48 <skvidal> ajax: continuing critpath rules for the release
19:43:50 <nirik> yeah.
19:43:50 <pjones> I'm +1 to using critpath rules on updates.
19:44:03 <mjg59> +1 too
19:44:13 <pjones> I thought that was explicitly before, actually.
19:44:17 <ajax> +1 to that, although i can see a slight wiggle room exception for the kernel due to the parallel installability.
19:44:20 <nirik> +1 here too as we are going to be implementing this for our updates policy anyhow and I think it makes sense to possibly make a more stable f13 until we do.
19:44:32 <ajax> whereas for release you only get one kernel to work with
19:44:56 * lmacken already made this critpath change to his local bodhi.git repo last night
19:45:17 <nirik> #agreed will re-enable critical path for f13 updates post release.
19:45:43 <nirik> lmacken: welcome. :) Any idea on ETA for the new crtipath loading/other updates related bodhi tickets?
19:46:20 <Kevin_Kofler> So we're prematurely implementing parts of the update process through a backdoor (redefining an existing process to mean something it was never meant to mean). :-/
19:46:30 <Kevin_Kofler> This is going to confuse our maintainers.
19:46:42 <Kevin_Kofler> Having processes implemented piece by piece is chaos.
19:46:44 <nirik> There's no backdoor... just doing this part of the new policy now.
19:46:55 <ajax> Kevin_Kofler: it sure sounds like everyone who just voted for it thought it was supposed to be this way all along.
19:47:01 <lmacken> nirik: the dynamic critpath list loading is blocking on the pkgdb... the critpath /handling/ policy can be pushed to production this/next week if we wish
19:47:01 <ajax> i hardly call that a backdoor
19:47:05 * nirik can draft/send an announcement about this.
19:47:09 <notting> Kevin_Kofler: we're having post-release work the same way as pre-release. arguably, that's *less* confusing.
19:47:22 <Kevin_Kofler> ajax: NFR has never been about updates.
19:47:34 <nirik> #action nirik will write up a announcement for fedora-devel about critical path for f13 release.
19:47:36 <ajax> i wasn't aware we were discussing NFR.
19:47:38 <abadger1999> lmacken: Are we still blocking on the generation script?  Or actually just the pkgdb-which-group-to-allow update?
19:47:38 <skvidal> so the vote is over, right?
19:47:38 <Kevin_Kofler> So redefining a part of NFR to cover updates doesn't make sense.
19:47:41 <lmacken> nirik: I need to make another pass at that ticket list before I can give a real ETA... I need to determine what features *need* to make it into the current bodhi codebase, before I can dive into the TG2 re-write
19:47:49 <nirik> lmacken: ok.
19:47:52 <ajax> i was pretty sure we were discussing updates policy.
19:47:55 * abadger1999 can push that as a hotfix tomorrow as we'll be out of release freeze.
19:48:08 <lmacken> abadger1999: the script only required a 2 line patch, which I haven't pushed yet.  Waiting on the pkgdb acls for it before I test it out
19:48:09 <nirik> abadger1999: can you coordinate with me on announcement before you do?
19:48:22 <Kevin_Kofler> ajax: The particular part of critpath handling we're discussing was introduced as part of NFR.
19:48:26 <abadger1999> nirik: It will be the bodhi piece that actually does anything.
19:48:39 <ajax> if that helps you sleep at night.
19:48:53 <nirik> ok, anything more on this ?
19:49:07 <Kevin_Kofler> No. Move on please.
19:49:14 <nirik> #topic Elections
19:49:21 <pjones> we should elect some people.
19:49:24 <nirik> Elections are still open... please remember to vote.
19:49:28 <skvidal> when do they end?
19:49:35 <nirik> https://admin.fedoraproject.org/voting/
19:49:41 <pjones> We need "I voted" stickers for Users:Blah wiki pages :P
19:49:42 <skvidal> and when can I take this meeting off of my calendar?
19:49:43 <nirik> tomorrow at 23:59
19:49:44 <Kevin_Kofler> So when is the last meeting of the old FESCo going to be? Is today the last one? Or next week?
19:49:47 <Kevin_Kofler> Or the week after that?
19:50:13 <nirik> I guess this is the last meeting of this fesco then?
19:50:26 * skvidal goes to adjust his calendar appropriately
19:51:01 <nirik> (well, for the 5 people who's seats are up)
19:51:11 <notting> do we usually have both present at the next meeting to install the new fesco? i forget.
19:51:20 <skvidal> notting: oh... let's not. :)
19:51:38 <jwb> not for anything more than "thanks!" and "welcome!"
19:51:43 <nirik> notting: I don't think we do typically... but it's an open meeting. ;)
19:52:17 <notting> ok then. so i suppose the first agenda item next week is meeting day/time, as usual
19:52:24 <Kevin_Kofler> Well, if I'm supposed to be present, but not having voting power, count me as "absent for unknown reasons". ^^
19:52:28 <nirik> notting: yeah, and chair...
19:52:58 <nirik> #topic Fedora 13 release
19:53:21 <nirik> Just like to say some kudos for all the hard work people have put in on Fedora 13. I hope it's a great release for everyone.
19:53:47 <Kevin_Kofler> Yay!
19:53:54 <nirik> If anyone would like to single out any folks who went over and above, feel free to do so. :)
19:54:41 <nirik> I think the QA folks did a great job this cycle... :)
19:55:06 <pjones> I think I'm glad it's done ;)
19:55:20 <mjg59> It's a release to be enthusiastic about
19:55:57 <nirik> agreed. Working nicely here...
19:56:03 <nirik> #topic Open Floor
19:56:07 <nirik> Anything for open floor?
19:56:09 <skvidal> fes ticket?
19:56:14 <drago01> can simply agree that it sucks ... more motiviation to do it better next time ;)
19:56:21 <nirik> oh, oops.
19:56:25 <nirik> #undo
19:56:25 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2309ddd0>
19:56:34 <nirik> #topic FES report
19:56:39 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
19:56:55 <skvidal> I added a ticket before the meeting to see if someone wants to chase down pkgs with file-requires outside of *bin/* and /etc/*
19:57:07 <nirik> ticket https://fedorahosted.org/fedora-engineering-services/ticket/15 was solved... porting isohybrid to c.
19:57:15 <nirik> skvidal: good one.
19:57:17 <skvidal> it's really not that many pkgs left and it would be nice to be clear of all the crack.
19:57:51 <nirik> agreed.
19:58:21 <nirik> on ticket #17 - Investigate implementing cross desktop support shortcuts. I was wondering what folks thought about adding more support info to start.fedoraproject.org.
19:58:29 <nirik> Or do we want to avoid adding anything there?
19:59:07 <notting> what does websites/design/board think? I'd be ok with some links there, but i'm open to other ideas.
19:59:11 <nirik> (thats https://fedorahosted.org/fedora-engineering-services/ticket/17 for folks that want to click)
19:59:26 <Kevin_Kofler> It might make more sense to have per-desktop shortcuts.
19:59:34 <Kevin_Kofler> E.g. point KDE users to #fedora-kde.
19:59:55 <nirik> yeah, might make some sense for that...
20:00:24 <nirik> anyhow, feel free to add feedback there to the ticket.
20:00:44 <nirik> mmcgrath: anything else to report this week on FES tickets?
20:01:09 <skvidal> I suspect mmcgrath is busy today
20:01:14 <skvidal> what with the release and all
20:01:15 <mmcgrath> yeah sorry
20:01:24 <nirik> yeah.
20:01:47 <mmcgrath> I don't have any major points except to mention that the NVR email I sent to packagers was quickly responded to by most packagers.
20:02:05 <mmcgrath> most that had the problem just weren't aware of it and were happy to fix it and happy they got notified.
20:02:27 <nirik> we might want to see about adding a scheduled item to do that each release cycle.
20:02:30 <nirik> or regularly.
20:02:53 <abadger1999> How goes getting people to work on tickets that haven't been picked up already?  (I assume those are the harder tickets).
20:02:59 <notting> nirik: agreed.
20:03:09 <mmcgrath> nirik: already did, I had poelcat add it to the schedule to be done right after the alpha
20:03:14 <Kevin_Kofler> How many NVR issues are left?
20:03:16 <nirik> mmcgrath: cool.
20:03:25 <mmcgrath> it's listed as a QA task but with me as the owner at the moment
20:03:40 <mmcgrath> Kevin_Kofler: generating list now
20:03:42 * nirik wishes for AutoQA to arrive and test for it
20:04:05 <Kevin_Kofler> I think we all do.
20:04:23 <mmcgrath> Kevin_Kofler: http://www.fpaste.org/9meS/
20:04:58 <nirik> mmcgrath: thats f12+updates -> f13+updates ?
20:05:09 <nirik> or f12+updates -> f13
20:05:20 <mmcgrath> that's f13, f13-updates-testing, f13-updates, f12 and f12-updates.
20:05:33 <nirik> ok
20:05:54 <Kevin_Kofler> Uhm, IMHO an issue is only fixed once the update goes stable.
20:06:06 <Kevin_Kofler> Those EVR updates should be pushed directly to stable.
20:06:44 <nirik> mmcgrath: yeah, without updates-testing might be interesting as well.
20:06:52 * mmcgrath isn't sure the reason some are in testing
20:07:02 <nirik> anyhow, anything further on FES tickets?
20:07:07 <mmcgrath> nope
20:07:15 <nirik> #topic Open Floor
20:07:21 <nirik> ok, open floor again. ;)
20:07:45 * nirik will close out the meeting in a few if nothing comes up
20:08:33 <nirik> Thanks for coming everyone. Go and enjoy Fedora 13! :)
20:08:37 <nirik> #endmeeting