FESCo-2007-11-29

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* f13 is here.
poelcat here
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* dgilmore is here
tibbs|h here
nirik is here.
* jwb is here
jeremy is here
c4chris is here
spot is here
dwmw2 here
linux_geekbpepple .. linux_geek here ( new joinee.. if you allow )
* nim-nim is here if needed
bpepplelinux_geek: your allowed.  we just ask that folks don't go off-topic.
--- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01850.html
jwblinux_geek, anyone is welcome to be here.  but only FESCo people can vote :)
linux_geekthanks bpepple and jwb .. but i guess .. iam allowed to work with you folks, if okay
bpeppleok, the FPC had a proposal for font packages, anyone object to it?
* nirik thinks thats fine.... including the comps stuff.
c4chrisno objection
dwmw2seems reasonable
f13no objection
* bpepple didn't have any problem with it either.
dgilmoreseems ok to me
jwbfine with me
jeremylooks fine to me
tibbs+1 from me.
* warren here
bpeppleok.  I don't see anyone objecting to it, so I think we can safely move on.
--- bpepple has changed the topic to: MISC - Fonts Comps Policy - http://fedoraproject.org/wiki/PackagingDrafts/FontsComps - Nicolas Mailhot
nirikthats the same text as the end of the fonts policy right? looks ok to me.
we should make sure existing font packages are made to conform to it tho if there are any that don't.
f13+1 from me.
dgilmoreseems ok to me also
f13and yes, I"d like to see a plan of action for existing packages.
dgilmorenirik: we should make sure all fonts are put in
bpepplenirik: agreed.  I think Nicolas was wondering what group was in charge of the comps package (FPC, FESCo, etc).
dgilmorebpepple: everyone is responsible for the comps files
warrenwhat has been the cause of comps corruptions?
nim-nimbpepple: in fact FPC wrote last week comps was outside its area, and ask you about it
dgilmorebpepple: you are responsible to add your own  packages
f13warren: rsync and/or netapp
warrenoh
f13only twice have I seen it be malformatted at the source
c4chrisfine with me
tibbsFPC didn't feel it had jurisdiction over what went into comps where.
* nirik has had anoyances with comps on his mirror this morning, but thats off topic for here...
tibbsI think the FontsComps document makes sense.
I'm just not aware that we have other guidelines about comps which are so specific. Maybe we need some.
bpeppleok, we should probably move on.....
nim-nimtibbs: other broups do not have tons of small packages, have you seen mizmo's monster fonts wishlist?
tibbsI have not.
--- bpepple has changed the topic to: MISC - Drop orphans from F8< at some point during F9 - f13
nim-nimtibbs: here http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline#wishes
nirik nim-nim
f13Oh that's me (:
warrenf13, have you checked on the status of the really short list?
f13warren: no?
linux_geeksorry to interrupt .. any work for me .. if possible ?
* warren looks at it real quick
warrenbpepple, can we go to the next one then come back to this immediately thereafter?
bpepplewarren: np.
c4chrislinux_geek: I think you want the admin meeting later on...
* f13 is a little confused that warren sent mail out on this already, I didn't think fesco had approved this yet.
--- bpepple has changed the topic to: MISC - Using Matt Domsch's "doesn't rebuild" bugs as AWOL detection, mark as orphaned at some point in F9, drop in F9+
warrenf13, we decided we would come back to it after the announcement warning had some time.
f13ah
warrenf13, but I suspect there are none left.
f13, so I'm checking now.
f13k
nirikyeah, I think they all got picked up... but not sure.
f13THis topic ties in a bit with last topic
bpepplef13: the next topic also.
f13Matt does full rebuilds fairly often and identifies a lot of potential problems.
nirikI would like to see a more concrete proposal. With details...
f13I'd like to have those be filed in bugzilla and attached to a tracking bug
and we can track those bugs as part of discovering MIA maintainers
jwbso matt's builds cover i386 and x86_64 right?
f13We would mark the package as orphaned at that point, so that it could be cleaned up later if nobody claims it.
jwb: I think so yes.
dwmw2yeah. I keep meaning to get round to doing the same on ppc (and ppc64 I suppose)
all architectures SHOULD do it, as far as I'm concerned
jwbso if ppc does the same, can we use those as bugs as well?
dwmw2of course
jwbi mean bugs to track MIA maintainers
f13jwb: I see no reason why not.
jwbok
nirikI think it's a fine idea, but I think there should be concrete details... how long do they have? when is someone marked awol... if it builds again does it reset?
jwbnirik, agreed
dwmw2if a maintainer can't even say "I'm too lazy to fix it; I'll ExcludeArch and put this bug on the FE-ExcludeArch-ppc tracker" then I think that meets the definition of 'missing in action' :)
f13nirik: I had assumed the same rules that FESco has used in the past to find MIA maintainers when they did forced mass rebuilds.
bpepplef13: seems reasonable to me.
nirikI don't know that those rules are written down anywhere...
http://fedoraproject.org/wiki/PackageMaintainers/Policy/AWOL_Maintainers is what we have.
f13yeah, so maybe I'lll have to come up with my own.
but if FESCo likes this idea in principle I can then spend the effort to work up a full proposal.
I'm mostly just doing driveby stuff right now
nirikI like the idea... things that don't build do need to be fixed.
dgilmoref13: i think it is a good idea  and something we need
f13This should also satisfy those that thing we should just rebuild everything every day just for funsies.
bpeppleI'm fine with the idea.
f13and we have some bite to go with our bark, in that if you don't respond, your package goes orphane, and later gets garbage collected
c4chrissound fine to me
bpeppleok, I don't see anyone saying that this is a bad idea, so f13 I think you've got FESCo's initial approval to the idea.
f13ok.  I'll try to work on the proposal soon.
warrenOK, I have a complete orphan list now.
jwbi have one questoin
f13jwb: shoot
jwbmdomsch does these on his local mirror, and it takes a while to actually churn through everything.  which means some things fail that have already been fixed
are a few false positives fine, or do we want to look at doing this on the master repos?
f13I'm not sure.
dwmw2why not do each build from a current mirror, rather than snapshot and then run the whole set?
nirikI think the policy could reflect that it should be for packages that don't rebuild over a long period of time... not just once off.
f13I'd be more than happy to try and help him make it either A) faster, B) more tolerant to false positives, etc...
jwbnirik, yes
c4chrisnirik: yes
f13sure, we can play some games with how many cycles it has been since it was noticed that it didn't rebuild.
warrenhttp://fedorapeople.org/~wtogami/temp/rawhide-removals.txt  Packages orphaned since before F8 that are still orphaned in devel.  (whenever we get back to this topic)
jwbdoes he do these builds weekly or monthly?
f13jwb: don't know.
nirikand keep track of NVR to make sure it wasn't a new version that also stopped working.
jwbf13, that would be important to know too.
i don't really want to bring it internally. i think having mdomsch run them is fine, and shows that not everything needs to be hosted here
nirikif we use this as part of awol policy we can perhaps ask that they be done once a month or something on a schedule
f13nirik: there was a request to rename "awol" to "mia"
jwbyeah.  some statement about frequency of builds would be good when determining the time periods
f13nirik: indeed, that was my thought.
bpeppleok, anything else on this, or should we go back to the orphan topic?
nirikneither is that great... 'nonresponsive maintainer' 'orphaning package'... not sure. Oh well.
--- bpepple has changed the topic to: MISC - Drop orphans from F8< at some point during F9 - http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt - f13
f13MIA makes it sound less like they're goign to go to jail (:
nirikstill has that war type feel to it though...
f13yeah, but MIA has a much different meaning than AWOL (:
jwbback to the topic...
f13anyway, I'm OK to move back to last topic
jwbwhat was the criteria here again?
bpeppleok, warren had this list of orphans: http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt
jwboh orphans
warrenjwb, orphaned prior to F8, currently still orphaned in devel.
poor orphans
* c4chris sees that e.g. cdiff already has a dead.package file in its /devel
warreneclipse-emf looks important?
f13right.
c4chriswhat more is wanted ?
f13I want to start some active garbage collection
dgilmorewarren: thats all?
warrendgilmore, yes
jwbc4chris, blocked from the repos
dgilmorewarren: i expected more
f13if it has been orphaned for over a release, I want to block it and drop it.
warrendgilmore, the list as of 2 weeks ago was real short, and many were claimed
dgilmoref13: can you kill them today
c4chrisjwb: blocked how ?
nirikI say block and drop after this meeting.
warrenisn't eclipse-emf important?
nirikif anyone screams they can revive them.
jwbc4chris, blocked in koji and removed from rawhide
dgilmorewarren: if it is someone will yell
jwbc4chris, e.g. the package will no longer exist
f13what I'd like to do is set up a predictable date each release that we would process the drops
jwbexcept in CVS
c4chrisjwb: you mean there still is a cdiff-*.rpm in rawhide ?
nirikI think the eariler the better...
dgilmoref13: 2 weeks after release
f13so that it's scheduled and known ahead of time, and reasonable enough time to clean up any messes it introduces
bpeppledgilmore: +1
nirikdgilmore: +1
tibbs+1
f132 weeks after release, maybe.  WHy not tie it with the point when we retire the old Fedora too?  one month?
warren+1
f13cluster the important dates if you will.
dwmw2just seems a little weird to me to drop unsupportable stuff _after_ the release
dgilmoref13: that would be ok also
dwmw2given that these are all going to be leaf-node packages, I'm half tempted to suggest two weeks _before_ the release :)
bpepplef13: I'm fine with that.
c4chrisf13: sounds good
f13dwmw2: a package could become orphaned at any point during the release, we can't drop it before the release if it's going to throw up a bunch of broken deps or has been in pre-releases and expected to be in final.
nirikf13: fine with me too.
f13dwmw2: they aren't always leaf nodes.
dgilmoredwmw2: a few times there have been many packages depending on them
dwmw2I suppose so.
poelcatstarting with F10?
c4chrispoelcat: ?
dwmw2poelcat: you mean starting 1 month after F9?
poelcatdwmw2: yes, when would we start this new prohcess?
c4chrisnow ?
f13poelcat: the idea is to flush what we have now, and have a scheduled flush 1 month after F9
c4chriswhen we drop FC-6
f13er yeah whoops
not now, when we drop FC-6
poelcatgot it
dgilmorec4chris: i think we start immediatly
* f13 gets his dates screwed up.
jwbc4chris, answer to your cdiff question: no.
warren, why is cdiff on the list?
f13dgilmore: why would we do it earlier this release than we would next release?
dgilmorehave someone send an email to fedora-devel-announce  stating whats going on and why
f13: i mean with this release
f13dgilmore: mail was already sent
but we can re-send and update yes.
that would be absolutely necessary
dgilmoref13: and state that orphans will be dropped from rawhide when  a release is dropped
warrenjwb, oops
jwb, I put the list together manually because there wasn't a programmatic way to query it
jwbheh, ok
* poelcat should add the drop FC-6 date to the schedule... what is it?
warrenThere is no cdiff on the list.  You're crazy.
nirikdec 7th I think
f13one month after F8 was released
so Dec 8th
poelcatsaturday? :)
f13well... (:
dgilmoref13: dec 7th
f13sure why not, happy friday
jwbwarren, heh
jeremyinformation on when the last fc6 update push will be was already sent
nirikwe announced the 7th I guess... https://www.redhat.com/archives/fedora-devel-announce/2007-November/msg00000.html
jeremyyeah, there's the mail I was looking for
bpepplef13: anything else on dropping orphans?
f13good
f13bpepple: I don't think so, it seems we're all in agreement that we should do this regularly
mdomschDec 7 is a day that will live on in infamy
f13all orphanes collected from the previous release will be purged one month after.
mdomschand it's a workday
so I figured that day would work out nicely
f13I'm ready to move on.
bpepplepoelcat: how much time you want for the features discussion?
poelcatbpepple: that is a dangerous question
f13hah
warrenpoelcat, argh, is it too late to write more features pages?
one key feature I didn't write yet
poelcatwarren: no; up until feature feeze
f13Can I have one more topic?
bpeppleI know.  we've got merge reviews to discuss, but I see that being a long discussion.
poelcatIn the interest of time... how about if we only do 4 or 5 features today?
http://fedoraproject.org/wiki/Features/Dashboard will remain current to voters
can review in advance of next week's meeting
bpepplef13: is it a quick topic?
poelcats/to/so
f13yeah, it's the more fequent automated conflicts checking with bugs filed and MIA detection.
--- bpepple has changed the topic to: MISC - Do more frequent conflicts testing, with bugs filed, and use AWOL detection
bpepplepoelcat: sounds good.  that will be the next topic.
f13ah
nirikthis is multiarch conflicts?
f13Just a quick blurb.  I'd like to see this done.
nirik: all conflicts
These bit us in the ass with the F8 release, so I"d like to detect them more early and more often.
jwbf13, can't we role that up with dep checks and such in bodhi?
nirikwhat other conflicts do we get? two packages with the same files?
f13also RPM is going to change so that conflicts are conflicts no matter when installed, either at the same time or in different transactions.
nirik: yes.
jwb: this isn't (just) for updates.
it's also for rawhide so that we can avoid having conflicts in the package set, which are not allowed
jwbneither should dep checks be
f13jwb: we get dep checks each night with rawhide
jwbright, that's what i'm saying
add it to the same scripts?
niriksounds fine to me... who is going to do that testing tho? for mia detection it should be folded into the policy when it's written up.
f13anywho, I'd like to have regular conflicts checks, with bugs filed, and tie into the other MIA + orphan detection we have going on.
jwb: potentially.
f13jwb: would depend on how much time it takes.
bpeppleI'm all for that.
jwbf13, yeah
f13nirik: jeremy ahs some scripts for detecting multilib stuff.
c4chrissounds fine
jwbaren't we going to kill multilib anyway?
jeremyhttp://katzj.fedorapeople.org/multilib-cmp.py
f13this could be someting we place out there as "we want this to happen, please somebody script this"
niriksure, go for it... it's worth noting that we should make sure not to re-file already filed bugs tho.
warrenWhat happened to the multilib plugin thing?
bpepplef13: +1
f13and if nobody gets to it maybe I'll get to it eventually
nirikthere are already a pile of multilib ones that notting filed.
f13nirik: yeah, any such script should have the capability of discovering already filed bugs.
warren: ask notting for a meeting recap
Ok, I'm done with this topic. I'll work on a write up for it along with the rebuild stuff.
warrenf13, which meeting?
f13 fab
bpepplef13: great. thanks.
--- bpepple has changed the topic to: FESCo-Meeting -- New Features - http://fedoraproject.org/wiki/Features/Dashboard - poelcat
* nirik guesses we aren't going to get rid of the way we do multilib in f9 either. sigh. ;(
bpepplepoelcat: floors yours.
--- poelcat has changed the topic to: http://fedoraproject.org/wiki/Releases/FeaturePresto
poelcatvote +1/-1
bpepple+1
nirik+1 here.
jwb+1 and i'd really like to see it happen with the koji refresh
spot+1
tibbs+1
c4chris+1 (just do not understand the "Ensure that changing files from a package lead to downloading the full package rather than the delta" thing)
dgilmore+1
jeremyI'm all for the feature, but there's still not much going on in the koji side of it :-/
jwbdamn
nirikis it likely to? is there anything we can do to get more movement on the koji side?
tibbsc4chris: I think the point is that if you modify non-config files, you don't want presto applying a delta to your modified file.
jwbnirik, code it?
warren+1
We need to talk about delta rpm generation implementation though. There are some differing opinions.
nirikjwb: would love to, but I haven't done any hard core coding in a while... ;)
f13jwb: I seriously doubt that will happen with the refresh
jwb: the refresh is early in Dec, and there os 0 code written for it in koji.
tibbsThe bottom line is that we want this, but if the koji integration doesn't happen then the feature will eventually be dropped.
f13I'm curious, jeremy are you still going to be a feature owner for this?
warrenI think the point is being missed here.
You don't actually need koji integration for this.
It can be done entirely asyncronously, and you probably want to for speed.
* spot needs to head out, sorry
warrenGiven that the repos work with or without delta's.
c4christibbs: oh, I see.  Didn't grasp that deltas apply to the installed files... somehow thought they were applied to the rpm
jeremyI really don't have time for pushing it right now
f13warren: are you offering to take ownership of this feature and work out a reasonable way to do this outside of koji that releng can review and approve?
mbonnetKoji is the wrong place for this.  Koji doesn't know anything about what actually gets pushed to the repos.  Bodhi would be a better place for it.
warrenf13, FINE, I'LL DO IT
It might query koji but it wont be part of any build process
or tree build
jeremymbonnet: the problem si that we don't want to have multiple places for storing things.  and especially given some of the interactions with signatures
* c4chris has a buzzing ear now...
f13It has to be a part of something so that the deltas go in place at the same time the other repodata does too.
mbonnetjeremy: but how do you know what to generate deltas against?
warrenf13, I was under the impression that deltas don't have repodata.  Maybe that changed.  I'll own it and see what's possible.
f13but since I don't have time to work on this, I'm not going to dictate how it's done.  I do however want releng to have a say before any method of publishing the deltas is "approved"
bpeppleok, I see eight '+1' for this feature, so we should probably move on.
warrenf13, sure.
jwbmbonnet, bodhi doesn't work for rawhide
jeremymbonnet: you have to say what you want to generate against.  but that's no different than having to specify a signature or collinst, etc
jwbbpepple, yes, lets
jeremywarren: there is metadata describing the deltas
bpepplepoelcat had to leave for a 2:00 meeting, so I'll take over for him.
warrenjeremy, I'll look into what is possible.
bpepplehttp://fedoraproject.org/wiki/Releases/FeatureKDE4
f13mbonnet: we have some reasonable assumptions.  We can see what's the latest build in the -gold tag, we can see what the latest build in the -updates tag is, etc...
--- bpepple has changed the topic to: http://fedoraproject.org/wiki/Releases/FeatureKDE4
f13I'm +1 for KDE4
bpepple+1
jwb+1
nirik+1 for kde4.
c4chris+1
dgilmore+1
f13looks like a very good write up.
tibbs+1
bpepplef13: agreed.
jeremy+1
bpeppleok, that's eight '+1', so the KDE feature has been approved.
--- bpepple has changed the topic to: http://fedoraproject.org/wiki/Features/OneSecondX
bpepple+1, sounds like a cool feature to me.
c4chris+1
nirik+several... sounds very nice.
jwberm.. +1
tibbs+1
f13+1
dgilmore+1
jeremylooked good to me, +1
bpeppleok, that's eight '+1', so we've approved that.
--- bpepple has changed the topic to: http://fedoraproject.org/wiki/Features/ServerProvides
bpeppleIs Patrice still interested in this? I seem to recall on the mailing list that he wasn't.
f13+1
nirikI like this one, but it should also get some noise... so 3rd party repos can pick it up.
in any case, +1
jwbthis one has the potential to be a rats nest
tibbsThe noise is one reason this is a "feature".
c4chrisjwb: --verbose ?
dgilmoreit seesm really fuzzy
jwbc4chris, i worry about having only part of the packages switch over
warrenSo somebody can write a SMTP server named "a" that wins.
jwbsome require smtpdaemon, some require server(smtp) (or apply that to any web port)
* dwmw2 is happy with exim winning :)
dwmw2 also has to go... sorry.
c4chrisI think it's worth a try
+1
f13warren: not a new problem, nothing to see here, move along.
dwmw2_gone+1
bpepple+1
warrenThis seems like a "minor" feature to me
does this really require a feature page?
this is a "blurb"
f13warren: it is, however since it touches many packages, and can have effect in our third party repos, it needs some voice.
c4chrisI think we need the noise factor
warrenOH... PR feature, I see.
+1
dgilmore+0
* jeremy is ambivalent, 0
warrenPropaganda Feature
abadger1999jwb: If it's policy and a feature for F9 then packages need to be changed to the new Provide:
jwbabadger1999, and become part of the guidelines, and have someone go through everything, and...
bpeppleok, I see six '+1', and two '0'.  anyone else want to weigh in?
jwb0
tibbs+1
bpeppleok, so we're at seven '+1' and three '0'.  This feature has been approved.
abadger1999Guidelines were fine for FPC; the second issue is why we wanted it to be a Feature.
bpeppleok, let's do one more feature, and then wrap up the meeting for this week.
--- bpepple has changed the topic to: http://fedoraproject.org/wiki/Features/XserverOnePointFive
bpepple+1
f13+1
jwbwhy is this a feature?
f13I saw a partial demo today, really fscking cool
tibbs+1
f13jwb: because it enables some really really cool shit
and if we don't brag about it, ubuntu will take all the credit
nirik+1
jwbok +1
c4chris+1
f13also, we'll likely be a driving force in getting upstream to release on time, and have had some testing on it
warrenanother Propaganda Feature
dgilmore+1
warren+1
jwbcan we mark these somehow?
f13warren: except that we're (RH) employing not a small number of people working on these features
jwbso idiots like me don't say "this is just a normal upgrade thing"
bpeppleok, that's eight '+1', so we've approved this feature.
dgilmorei do think that when we are first to implement something new we need to capitalise on it
f13it's not like we just get it for free when upstream gifts us with a tarball, we're actually doing the work to make it happen.
bpepplef13: agreed.
f13jwb: it's not just a normal upgrade thing.
warrenf13, right, it really doens't change the delivery of the feature though if we approve or disapprove of it here, so it is really only propaganda.
jwbf13, you could say the same about yum development, etc
anyway, offtopic
f13jwb: we could.  However more people use X than yum.
bpeppleok, is there anything else people want to discuss before wrapping up the meeting?
f13RH/Fedora is making this work happen, that other's are goign to get for free.
nirikI have a quick query...
f13Does anybody remember setting a deadline for kmod packages to go bye bye?
jwbNOW
tibbsYeah, I though it was "immediately".
nirikI have a request to grant a FC-6 branch exception for a xfce plugin... it was orphaned, it's back, and the maintainer would really like to provide it in FC-6 as well... see https://bugzilla.redhat.com/show_bug.cgi?id=392981
buggbotBug 392981: medium, medium, ---, Kevin Fenzi, ASSIGNED , Review Request: xfce4-modemlights-plugin - Modemlights for the Xfce panel
bpepplenirik: isn't it past the point of creating new branches for F-6?
nirikbpepple: yes. He wants an exception... I guess FESCO would be the one to grant that? or should I tell him no exceptions...?
f13I don't really see this ias a reasonable exception.
jwbwhich is why he phrased it as an exception...
f13FC6 is days away from being EOL, it's not like we're expecting new installs of it, or upgrades to it.
nirikhe just wants it in all releases... not skipping fc-6... but yeah, I don't care, just wanted to ask here about it.
tibbsI don't see why it would be "really bad" to have it in FC5 and F7 but not FC6.
nirikI guess the only way it would be 'really bad' is if someone upgraded to FC-6...
but we shouldn't be encouraging that.
abadger1999Will there be people upgrading from FC5=>Fc6=>F7?
f13I hope not.
jwbwhy would they do that
nottingwhen fc6 goes eol in a week or two?
f13that's just asking for 2x the potential for failure.
abadger1999ie, upgrading version to version instead of trying to do an upgrade all the way to latest?
tibbsThat would still just leave the FC5 package on the "fresh" FC6 system, which would then be upgraded to the F7 package.
c4christibbs: right
* abadger1999 remembers when people advised doing that.
nirik has nothing else. Thanks for looking at that.
bpeppleok, let's wrap up the meeting then.
* bpepple will end the meeting in 60
abadger1999tibbs: Wouldn't dependencies (in a yum upgrade) break that?
f13Ok, I'm going to send mail to the kmod maintainer(s) and let them know kmods are going to be blocked.
tibbsabadger1999: depends.
bpepplef13: cool.
* bpepple will end the meeting in 30
* bpepple will end the meeting in 15
warrenf13, will you mention that htey should work on getting included in the kernel?
(or upstream)
bpepple-- MARK -- Meeting End
f13yeah, I'll try to find references to when we talked about it
or passed the policy
bpeppleThanks, everyone!
tibbsabadger1999: If upgrading via anaconda, no, the package would be left on the FC6 system with broken dependencies, and then would be properly upgraded to F7.
c4chrisbpepple: thank you
tibbsAt least that's been my experience.
c4chrislater folks
bpepplewarren: I think I included that in my FESCo minutes from last week. http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20071119

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!