--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* c4chris waves
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* nirik is present.
* EvilBob looks up from the cheep seats
nirik sees that everyone upgraded their dircproxy... good.
jeremy is here
dgilmore is here
bpeppleok, let's get started.....
--- bpepple has changed the topic to: MISC - Are "spins" a feature? - poelcat, all
* tibbs here
warren here
jeremyunless we're changing the ones that we distribute via download.fedoraproject.org (ie mirrored vs torrent only), I don't think so
at least, not in the sense that we track features
jwbi agree
bpepplejeremy: I'm inclined to agree.
* nirik nods
jwbi see no problems with spin pimping on -announce and/or -devel-announce
jeremyjwb: agreed with that also
nirikI think it's still very good to tout them and announce them and mention them...
bpepplejwb: +1
jwbcaillon, nice :)
jeremythe board has said that they will approve up to one spin a month to add to spins.fedoraproject.org also.  and thus off the normal release schedule
* poelcat here
c4chrisfeature-- pimp++
caillonjwb, it sounds much more czech that way :)
jeremyand spins.fedoraproject.org is going to rock when the design for it is finished up :)
bpeppleok, does anyone disagree with spins *not* being features?  If not, we can probably move on.
jwbjeremy, one spin a month irrespective of the release cycle?
caillonup to
nirikwhy only 1/month? capacity issues?
jeremyjwb: the impression I got was up to an additional one per month.  and releases are obviously a little different
nirik: capacity, reducing brand dilution, etc
caillonnirik, that and i guess we don't want a really popular spin to take away from maybe not as popular a spin, etc
nirikwell, seems strange to have a limit like that, but whatever.
bpeppleanything else on this?
bpepplemoving on...
jeremylooks like a no to me :)
--- bpepple has changed the topic to: FESCO-Meeting -- Plan to get Merge Reviews finished by F9 -- all
bpeppleOk, we set a deadline for the merge reviews to be finished by F9.  Is that still reasonable?
warrenWithout full buy-in from Red Hat engineering to 1) help with reviews 2) make engineers responsible to respond to reviews is this possible?
jeremyif we want to accomplish that, it's going to require drumming up more people doing reviews.  I mean, tibbs can do a lot of them but ... :)
nottingnot sure a deadline is practical. we're going to kick out packages?
caillonand what happens when the deadline passes and we aren't done?  (because that's pretty likely, sadly)
bpepplejeremy: agreed.  Our past attempts to get people to help out have been pretty fruitless.
nirikyeah, I still don't see a good way to do this other than slowly.
warrenA BIG HELP here would be making RH engineers responsible to actually respond to review suggestions.
tibbsYes, that's the major barrier for me.
nirikdoesn't help that after the bugzilla changes the other week everything's timestamp got reset.
jeremyI can try to beat that drum again
c4chriswarren: that's my impression too
poelcatwarren: is there a way to split out which reviews are dependent on Red Hat engineers?
caillonmaybe we can get some funding to give out swag to those who do N number of merge reviews?
warrenwell, if NEEDINFO is set to a @redhat.com person?
jeremycaillon: if the board wants to fund that... :)
caillonjeremy, i can bring it up next meeting!
warrenpoelcat: if (Merge Review && NEEDINFO is set to a @redhat.com person)
nirikI think we need both reviewers _and_ responding redhat folks...
nottingwarren: that being said, querying for *who* needinfo points to is nigh impossible in bz
bpepplenirik: agreed.
warrennotting, sigh
tibbsnirik: Yes, but I tend to give up after not receiving any response.
I can only keep track of so many reviews at the same time.
niriktibbs: yeah, I haven't done any in a while for that reason... hard to go thru all the trouble to get no answer. ;(
poelcatwarren: send me a list and I can take to dev managers at next meeting to see what their teams can reasonably commit to
caillonhow many are outstanding?
jimahow about Merge Review && NEEDINFO and deal with hand-sorting the non-RH ones?
tibbsI currently have eight merge reviews stalled.
warrenpoelcat, this isn't a matter of a one-time list
poelcat, it needs to be policy
tibbsSorry, eleven.
warrenpoelcat, responsible length of time to respond to certain types of Fedora tickets
poelcatwarren: i thought we were talking about the backlog?
caillonwarren, well this sort of *is* a one time list though because we aren't going to have more merge stuff in the future
poelcatwarren: you are introducing a second issue
nirikI only see 551 on the new list.
abadger1999If we kicked everything out of rawhide that isn't in review now (because it's the start of a cycle) we'd get reviews to happen
warrencaillon, no, because new NEEDINFO will appear as more merge reviews happen
* abadger1999 is half joking half serious
tibbsabadger1999: That's just not practical, unfortunately.
nirikI have 13 stalled merge reviews.
warrenpoelcat, not exactly, it is the same issue
tibbsWe kind of need the kernel, after all.
caillonabadger1999, if you kicked out things that don't have review, i'd not have to do firefox errata for a while ;-)
jeremyabadger1999: unfortunately, we'd also end up without a distro
bpepplecaillon: doing a quick query I see 716 merge reviews.
abadger1999caillon: Hey!  Silver lining to everything :-)
poelcatwarren: but if you want to solve this we have to take it to them in managable pieces :) 1) backlog 2) going forward
c4chrisI'll see if I can color them red in the PackageStatus reports...
jwbso i have a question
warrenpoelcat, ok, sounds good
jeremyjwb: 37!
jimaholy carp, i didn't realize i had stalled merge reviews :(
jwbthis seems to me where FESCo should sort of step in and enforce the guidelines
f13here, sorry
XulChrisjeremy: wrong, its 42
caillonwhich base?
abadger1999jeremy: I'm not 100% serious but <devil's advocate>the costs of not having a distro for the first month of development would be balanced against how much we actually want everything in the distro to have undergone review.</>
c4chrisI don't see where we have a large stick to wield...
nirikwell, it's hard to enforce. I suppose we could orphan a package that has a maintainer that isn't answering merge reviews...
jwbso why can't we appoint some people, grant them cvsadmin access, and fix most of the smaller issues
jeremyjwb: I wouldn't be against something like that
bpepplejwb: I don't have problem with that.
nirikhow about this one: no updates to a package that hasn't passed merge review (for devel)
jwbi think if it's going to get done by F9, that's what it will take
c4chrisjwb: interesting idea
I kinda like it :)
jwbwe have a governing body for a reason :)
bpepplejwb: how big of a team are you thinking?
warrenjwb, some RH engineers will go ballistic
f13warren: I don't care.
jwbwarren, i know.  that is where jeremy and f13 will have to come in
EvilBobas long as they don't go postal
nirikwell, but that doesn't show that the maintainer can clean up their package? is the goal clean reviewed packages only? or also maintainers that know the guidelines?
warrenf13, I don't either, I was just commenting =)
caillonjwb, note that legislative is not executive :)
jwbbpepple, i'd look for volunteers first.  people FESCo trusts
jeremyjwb: I think it's only fair to let them try to respond to their merge review feedback first.  but beyond that, if they have a problem, they can deal
abadger1999Do we have a sense of how many packages are waiting on minor things vs "you need to make different subpackages and reexamine the need for suid" type changes?
bpepplejeremy: +1
jwbjeremy, yes agreed
jeremyjust like anyone who's upset that I rebuilt their package for openssl or openldap ;)
bpeppleabadger1999: I don't think we have any way to determine that number easily.
tibbsThere is the possibility of janitors just cleaning up the packages.
dgilmorenirik: its easy to enforce
nirik: releng blocks anything that hasnt passed review
jwbtibbs, to be honest, i like the idea of janitors in general
dgilmorenirik: people cry and get it fixed
jwbtibbs, for more than just merge reviews.  people to actively go over the specs and submit patches to adapt to updated guidelines, etc
tibbsThere's a class of minor issues which I can just fix, and a class of changes which I know I won't push because I lack the ability to test them adequately.
abadger1999nirik: Maybe for merge reviews the object is to get the packages in shape and in the distro even though that means we'll have a body of RH engineers who potentially will only know the guidelines well enough to rubber stamp one-another's package reviews... which is no different than today....
bpeppleProposal: FESCo appoints some people, grants them cvsadmin access to fix merge review packages that haven't had responded to.
c4chrisbpepple: I'd be fine with that
cailloni kinda like the idea of submitting patches, actually
jimaugh, my stalled review is pathetically trivial stuff.
tibbsBut what if I submit patches and they're ignored?
dgilmorebpepple: im somewhat ok withthat.  there is no way to enforce that the changes stick
jimabpepple: side note: there's some precident for the access (see sparc sig)
tibbsI took to submitting patches for my merge reviews because I found it actually simpler than describing the changes.
nottingdon't see how that's any different from the normal 'stalled' case
f13caillon: the problematic packages will just have patches sitting in bugzilla without getting applied, and then the maintainer will do other work on the package ignoring the patches.
(seen it happen)
caillontibbs, then nonresponsive maintainer process kicks in?
tibbsI don't know how that process works for Red Hat employees.
nirikso this mandate would be to fix the package to pass review? or just minor things? or ?
tibbsIf we only had a hundred packages left, a mandate would be something to think about.
f13tibbs: the process should work as is.  $employees manager will likely get a rude wakeup call when the package gets orphaned
jwbon a bright note, i believe the kernel already conforms
bpepplenirik: I would think for items to pass review.
jwbso at least people will still be able to boot :)
tibbsYes, the kernel got a bunch of good work.
I can go back and ping on all of my open merge reviews; maybe I'll get some movement.
nirikok, I guess I'd be willing to give it a try... but I don't think it's going to get them all done unless there is a vast amount of people in this group.
abadger1999jwb: What about grub? ;-)
jwbabadger1999, i use yaboot.  don't care ;)
tibbsBut does setting NEEDINFO actually do anything useful?  Does bugzilla pester people to respond?
nirikhow about as a show of force, everyone in fesco pledges to do 2 merge reviews before the next meeting. ;)
jimatibbs: it sends one more email, iirc
jeremytibbs: it sends mail.  but there's lots of bug mail
tibbsSo chances are, any ticket sitting in needinfo isn't being actively ignored, it's just dropped through the cracks.
f13it still shows up in mybugzilla front page
c4chrisI sure hope so
f13but likely most RH engineers don't use that
since they get lists of things to work in via other means (like flags for RHEL issues)
the amount of bugspam that rh engineers get is truly mind boggling
caillonit really is amazing that we get fedora stuff done
bpeppleok, so where are we on this?
poelcatso do we need a different/better nagging mechanism?
c4chrisso, to summarize, we could: 1. orphan 2. cvsadmin 3. bz pester 4. do nothing ?
poelcator is that solving the wrong problem
tibbsCan we try to set an "open merge review target" for F9?  And perhaps pick a set of packages that we want to see reviewed?
f13poelcat: I thikn that's solving the wrong problem.
nirikpart of the problem is also lack of reviewers... the bulk of them left is in NEW...
nirikof course getting the stalled ones moving will make reviewers more likely to review more.
f13poelcat: ideally, we get RHEL buy in that this work has to be done prior to RHEL6 forking from Fedora, so that engineers get some allowed time to work on it
caillonand the rather daunting review process
XulChrisreviews should not be rushed, i think deadlines are bad, but package maintainers need to put merge reviews at a higher priority, thats all
tibbsnirik: Yes, that's my issue.
poelcatf13: that is the missing piece IMHO
f13poelcat: because right now I think it's just viewed as busy work that "Fedora" is trying to force upon engineers, who have no cycles for busy work.
caillonmaybe it's easy for the seasoned reviewer, but it's really fricken hard if you're not reviewing packages all the time
jwbcaillon, i sadly agree
nirikcaillon: yeah, it could be made more streamlined for sure. ;(
caillonhonestly, i think that fixing the review process will help us get more reviews done
f13but I don't tink that can be done in time
warrenAsking RH engineers to review is a separate thing from asking them to be responsible to respond to reviews.  The latter has been a great discouragement to reviewers.
f13we're working on multiple fronts to improve things, there is only so many man hours to go around.
(or women hours)
(or even child hours...)
warrenf13, humanoid hours
jwbor eunic
nirikso as we work to improve things, how about tibbs suggestion? a target and a set of packages we would really like to see done by f9?
* poelcat votes for fixing the review process at FUDCon... or at least trying
XulChrisi reiterate that deadlines and rushing reviews is a bad idea
nirikthen hopefully things will get better on reviews and we can get more of the smaller packages done in the next cycle?
dgilmorepoelcat: :)
jeremypoelcat: that sounds like a good thing to target
jwbpoelcat, good
f13poelcat: works for me.
dgilmoref13: lifeform hours :)
tibbsNow I just hope I can make it to fudcon.
nirikwell, it just needs more automation, right?
f13dgilmore: but I have a robot do most of my work...
dgilmoref13: it is humanoid?
jeremynirik: sounds reasonable.  do you want to come up with a concrete proposal for what the target is, etc? :)
jwbon track people
XulChrisa graphical GUI review wizard would be neat
warrenf13, the real jesse playing Wii now?
dgilmoref13: i think that clasifies as lifeform
warrensentient entity hours
nirikjeremy: I could try... or tibbs? you want to come up with a list of likely ones?
poelcatin the meantime if we want some type of tangible commitment from RH engineering mgmt... we need something of a formal request to take forward to get buyin
tibbsObviously kernel, X, the base utilities.
nirikrpm is done except for a license review.
tibbsI did a bunch of X already, and ajax was nice enough to say "commit whatever changes you want".
warrenpoelcat, I put forward these suggestions about halfway through F8 cycle just to warn them that this was coming.
caillonhow many of the ones awaiting review are in the default install?
dgilmorehas anyone touched glibc and gcc yet?
* tibbs scared
jwbglibc should be reasonable
as should gcc
warrenJarod did a great job making kernel.spec more reasonable
jimatibbs: wow, nice of ajax
f13ajax is very reasonable and a great guy
tibbsjwb: The glibc spec is over 4K lines.
poelcatwarren: yes, but it needs to be a "request" not a "suggestion" this time :)
jwbtibbs, i meant from a maintainer interaction perspective
nirikglibc is waiting. I think someone looked at gcc.
jwbjakub owns both
dgilmorejwb: glibc and gcc are going to be painful
warrenpoelcat, it was a request
jwbwell, jakub and roland are fairly reasonable people
painful, but not insurmountable
f13glibc/gcc are likely going to be a pile of exceptions to our guidelines, just because they're /odd/ packages.
tibbsThat's true.
poelcatwarren: can you send me the email?
f13which I'm fine with
warrenpoelcat, it wasn't in e-mail, it was in meetings.
tibbsBut even the kernel came into line, and I don't think anyone disagrees that it's better now for all involved.
nirikgcc has had some guideline issues... it's not really under review.
warrenLet's not get all hung up on a small # of packages
bpeppleok, so tibbs & nirik will work on a proposal of packages to review, and we need to get buy-in from RH engineering mgmt.
warren: +1
tibbsbpepple: +1
c4chrisbpepple: +1
bpepplealright, let's move on since we've got a bunch of features to get through.
--- bpepple has changed the topic to: FESCo-Meeting -- New Features - http://fedoraproject.org/wiki/Features/Dashboard - poelcat
poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Releases/FeatureBluetooth
caillon(what does a +1/0/-1 mean for features again?)
tibbsThere's a whole lot of stuff there; is there really a chance that it's going to be done?
poelcat+1 = accept ; -1 = do not accept
jeremy+1, although I'd love to see a more concrete idea of what is being targeted as f9 pieces
dgilmoretibbs: it does seem like alot of things
f13caillon: "accepted" as something the project wants to see happen and will advertise it and help ensure it happens.
nirikI'd really like to see headsets work out of the box, and it would be cool to have the ps3 controller working. ;)  +1
f13caillon: making sure that it's not something stupid/illegal like "include mp3 support" or "include an image of windows"
f13caillon: just to keep some buffer between proposed features and the accepted features that press will pick up
jwbthis is something we touted as a feature in F8 as well
nirikyeah, if the feature owner could weed down to whats really targeted for f9 that would be great... or note that it all is.
f13caillon: and to help us keep a handle on how many "features" we "missed" for a release.
dgilmorenirik: i want dun to work  though i think i need to slap blackberry for that
tibbsBy all means, though, +1 and more power to them.  But I have doubts that this is all implementable before we freeze.
caillontibbs, so the page gets re-written then
poelcatin talking to hades.. he realizes it might not all get done and he will adjust/fork the page at feature freeze
caillon(which makes me sort of wonder about the value of voting NOW, but that's a separate issue ;-)
f13that's fine.
poelcatfork as in move unfinished stuff to f10
f13this is one of those cumulative improvement things.
caillonf13, yep
f13caillon: we're not so much voting on what all will get done, we're voting on the idea of getting /something/ done so that we can brag about it
poelcatcaillon: we already voted on the feature process for f9 :)
bpepplepoelcat: ok, I see seven '+1' on this, so the Bluetooth feature has been approved.
--- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Releases/FeatureClockApplet
i'm using this right now and love it
bpepple+1, looks cool.
poelcatlooks like 7 +1s ... moving on
--- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/PartitionResizing
* jeremy abstains as the person writing code
poelcatlooks like 700 +1s ... moving on
--- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/VirtStorage
c4chrisf13: you used up all your voting points ... ;)
* poelcat wrongly used "*" instead of "+"
nirik+1 good stuff...
--- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Releases/FeatureFingerprint
f13for the last one, +1 for this one
make my fingerprinting better!
bpepple+1, wishes he had a fingerprint reader on his lappy. :(
jwbdoes fprint replace thinkfinger?
caillonjwb, yes
f13I do believe so
nirik+1, but note that it would be nice if they don't only do gnome work... kde/xfce want fingerprints too
f13if nothing else, stop doing an extra newline when sudo envokes thinkfinger stuff.
jeremyjwb: that's the idea
f13sudo yum foo always gets a "no" due ot an extra endline
--- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/PackageKit
caillonf13, not always for me
* jeremy thinks that promoting two different package management frameworks is utter insanity
f13caillon: I get it every single time I sudo for the first time, where it would prompt.
tibbs+1 packagekit
jwbi have no idea what packagekit will even do
warrenI would vote +1 if we get to try it and change our mind later.
c4chrisI'm a bit uneasy about that one...
nirikdoesn't it use yum/rpm as a backend?
nirikso it's just a spiffy new frontend?
nottingunlike smart, apt, etc. it's still using yum. so +1 from me
jeremywarren: the problem is that since we're saying it's a feature, we go off and say "Hey!  Go look at PackageKit!" while at the same time working on other stuff.  it's so schizophrenic it's not even funny
warrenjeremy, what is the other stuff in parallel?
f13nirik: not quite.
jwbis it supposed to replace pirut/pup?
jeremywarren: pirut, pup, etc.  you know, the toolset that we've been working on
warrenjeremy, survival of the fittest...
f13nirik: there is a /scary/ amount of "backend" code for yum in packagekit, which has lots of potential for thigns to go wrong.
nirikhum. Is it available in f8 as well? or just rawhide?
f13and bizarre things like hardcoded grouplistings
nirik: I think just rawhide
c4chrisI'm fine to have it in Fedora, I'm just uneasy to tout it as a feature that folks should try out...
jwbwarren, then you'd have to promote pirut/pup as a feature
caillonmeanwhile other distros will
* nirik nods at c4chris.
warrenI think it would be a mistake to give them a blanket "no", but it would also be a mistake to tell them "yes" without conditions.
jeremyit's one thing to include packages, but saying PackageKit is a feature means that I'm going to write up the apt-rpm and smart feature pages as well because they're just as much a feature
caillonand take the credit from what fedora guys (who we aren't even paying) are writing
notting? the idea of package-kit is to give a cross-distro way to integrate into the package manager. we *do not have that anywhere else*
so upstream people who want to hook into the package manager don't need to write separate deb/rpm/yum/etc. code
warrenLet's give them a chance.
jwbnotting, so it's like libvirt, but for package managers?
jeremynotting: sure we do!  everyone can use apt!
nottingif libvirt were only proddable via dbus... yeah, sort of.
EvilBobjust because a tool does almost the same thing as another tool does not make it bad, it could end up better with a little support and help.
jeremynotting: or they can use smart.  both are available for lots of package managers
tibbsWe don't have to approve this now.
jwbnotting, i meant it's abstraction API?
c4chriscan we punt this one 'til next week please ?
caillonjwb, parly yes.  it also ships with a gnome gui (and there's a kde one that others are working on)
bpepplec4chris: +1.
nottingjeremy: and you're objecting to it on the grounds of pirut/pup which... don't.
dgilmorecaillon: i know there is a qt4 based on out there
jwberm... i vote to delay voting
nirikyeah, I would like to go look at it... next week sounds good to me.
caillonso cool dudes from Fedora started working on packageKit... writing it with a gnome frontend, and already we have 2 or 3 *other* frontends...
isn't this exactly what features are? cool things we want to tout?
f13caillon: pretty much yea.
bpepplecaillon: I agree.
caillonif it's cool enough for every other distro to get involved and port it to whatever toolkits, why are we delaying voting?
* poelcat counts 5 "+1"
warren+1 unconditional
f13toss my +1 in there, but I'm uneasy of Yet Another Package Codepath
it's not like we don't have issues with the few we have.
* poelcat thinks that is 7 ?
nirikI would kinda like to look at it more, but I guess +1
f13and it's going to make adding features to yum that much harder, if we're comitting to keeping PK working.
poelcatanything else on PackageKit?
nottingf13: we break yum-utils and yumex all the time. why is this different?
bpepplepoelcat: I don't think so.
EvilBobIMO if PackageKit uses yum it is up to PackageKit to make sure it works with yum, not yum's issue.
--- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/Ext4
jeremynotting: because we never said that yumex was a feature of the release.  nor yum-utils.
skvidalEvilBob: umm, it never works that way
poelcatjeremy: that was before the feature process ;-)
nottingjeremy: if yum-utils isn't a feature of the release, it should be.
bpepple+1.  btw, Ted Tso does some pimpin for us on this here: http://www.linux-mag.com/id/4555
warren+1 there will be complaining by people who try to mount from older kernels like we added xattrs to ext3, but in the end we were better off.
notting+1, although everything i've heard about ext4 is a 'why should i care' thing
jwbhas davej agreed to carry patches for it?
f13+1 for ext/me waits for page to load.
nottingjeremy: also, yum-utils is a default package :P
warrennotting, you don't have exobyte arrays at home?
tibbs+1 ext4
I definitely want larger thatn 8TB support; I hit that often enough now.
jeremyext4 isn't loading, but sure!   although how visible it's going to be is still up in the air
jwbhas davej agreed to carry patches for it?
tibbsIt's in F9 currently, isn't it?
rsc+1 ext4
* poelcat counts 8 +1
tibbs"a devel version of ext4 exists in the F9-devel kernel today"
jwbtibbs, with patches, yes.  and since f9 is a -rc kernel, that's fine
dgilmoretibbs: your a storage anomoally
jeremyjwb: yeah.  sandeen is staying on top of making sure they don't break compiling
jwbjeremy, ok
--- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Releases/FeatureTexLive
tibbs8TB is only 9 drives these days.
c4chrisvery large data is coming real fast in genomics...
tibbsFinally the reviews are completed.  Now we just need to get things to a nonbroken state.
* jwb is a kernel geek
jeremy+1 to texlive
notting+whatever, it already landed.
* poelcat counts majority == yes
tetex was blocked today.
poelcatshall we stop here for this week or knock out the last two today?
tibbsI have time.
f13I have a topic
f13it's tomorrow.
* nirik cheers!
EvilBobf13: +1000
f13releng has a plan for what we need tod o releng wise
not sure what needs to happen wiki wise
bpepplepoelcat: how about we punt them to next week?
jwbwe do?
f13and a lingering question regarding bugzilla.
jwb: I posted to rel-eng@fp.o
poelcatbpepple: okay
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
warrenExtras is finally dead
bpepplepoelcat: thanks.
* lmacken can't wait to kill the original updates system
f13lmacken: me too
tibbsBut we can't get rid of plague yes..
f13let me dump the releng tasks
caillonlmacken, hey don't knock the old system
bpeppletibbs: right, isn't it used for EPEL still.
f13Disable internal update system (after pushing all updates, things in
testing, oh well?)
Do a last Extras push, disable it from push scripts.
Turn off internal build target for dist-fc6-updates-candidate
Turn off plague for FE6
lmackencaillon: i wrote it.. I can knock it :)
f13Turn off the Extras sync cron job internally
Disable/remove the bugzilla version?
Announce the end of life.
caillonlmacken, it works better than bodhi for me :p
f13Disable the updates cleaner.
warrenf13, can I add one thing?
f13warren: that's why I brought it up here
warrenf13, after last push, let's be sure we didn't add a terrible new broken dep.
f13warren: sounds great, when will you have the report in?
warrenthat's all.
f13there are currently no broken deps detectable in the push tool for Core 6, I have no idea what Extras looks like
dgilmorei will be stopping extras builds on friday morning
bpeppledgilmore: cool.
* nirik is sad that Xfce 4.4.2 didn't come out sonner, could have pushed it to fe6. Oh well, tough luck.
nottingsurely Zod is not being EOLd, only relegated to the Phantom Zone?
f13Can someone volunteer to trawl the wiki for FC6 mentions and fix 'em?
lmackencaillon: if by "works better" you mean "doesn't care about anything", then yeah :)
bpepplef13: I can work on that.  I'll have some free time tomorrow.
EvilBobbpepple: I will help out also
bpeppleEvilBob: thanks.
anything else? or should we wrap up for this week?
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
Thanks, everyone!

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