===================================
#fedora-meeting: FESCO (2010-05-25)
===================================
Meeting started by nirik at 19:00:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-05-25/fesco.2010-05-...
Meeting summary
---------------
* init process (nirik, 19:00:01)
* #340 #Determine and approve F11 end of life date (nirik, 19:01:33)
* AGREED: new f11 eol date is 2010-06-25 (nirik, 19:03:45)
* #381 #yelp dependency of gnome desktop apps (nirik, 19:04:17)
* LINK:
http://fpaste.org/406j/ (skvidal, 19:11:36)
* ACTION: mjg59 will talk to yelp maintainer(s) and see about PK
integration and/or a yelp-yelp stub package (nirik, 19:16:30)
* AGREED: recommend currently NOT to add yelp dependencies. Will work
on longer term/better solution from here. (nirik, 19:21:51)
* #351 Create a policy for updates - status report on implementation
(nirik, 19:22:34)
* AGREED: will re-enable critical path for f13 updates post release.
(nirik, 19:45:17)
* ACTION: nirik will write up a announcement for fedora-devel about
critical path for f13 release. (nirik, 19:47:34)
* Elections (nirik, 19:49:14)
* LINK:
https://admin.fedoraproject.org/voting/ (nirik, 19:49:35)
* Fedora 13 release (nirik, 19:52:58)
* FES report (nirik, 19:56:34)
* LINK:
https://fedorahosted.org/fedora-engineering-services/report/6
(nirik, 19:56:39)
* Open Floor (nirik, 20:07:15)
Meeting ended at 20:08:37 UTC.
Action Items
------------
* mjg59 will talk to yelp maintainer(s) and see about PK integration
and/or a yelp-yelp stub package
* nirik will write up a announcement for fedora-devel about critical
path for f13 release.
--
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