| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| * c4chris waves | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| Hi everybody; who's around? | ||
| * nirik is present. | ||
| jwb | here | |
| c4chris | here | |
| caillon | ||
| * EvilBob looks up from the cheep seats | ||
| nirik sees that everyone upgraded their dircproxy... good. | ||
| jeremy is here | ||
| dgilmore is here | ||
| bpepple | ok, let's get started..... | |
| --- bpepple has changed the topic to: MISC - Are "spins" a feature? - poelcat, all | ||
| * tibbs here | ||
| warren here | ||
| jeremy | unless 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 | ||
| jwb | i agree | |
| bpepple | jeremy: I'm inclined to agree. | |
| jwb | however | |
| * nirik nods | ||
| jwb | i see no problems with spin pimping on -announce and/or -devel-announce | |
| jeremy | jwb: agreed with that also | |
| nirik | I think it's still very good to tout them and announce them and mention them... | |
| caillon | spimping | |
| bpepple | jwb: +1 | |
| jwb | caillon, nice :) | |
| jeremy | the 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 | ||
| c4chris | feature-- pimp++ | |
| caillon | jwb, it sounds much more czech that way :) | |
| jeremy | and spins.fedoraproject.org is going to rock when the design for it is finished up :) | |
| bpepple | ok, does anyone disagree with spins *not* being features? If not, we can probably move on. | |
| jwb | jeremy, one spin a month irrespective of the release cycle? | |
| caillon | up to | |
| nirik | why only 1/month? capacity issues? | |
| jeremy | jwb: 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 | ||
| caillon | nirik, that and i guess we don't want a really popular spin to take away from maybe not as popular a spin, etc | |
| nirik | well, seems strange to have a limit like that, but whatever. | |
| bpepple | anything else on this? | |
| bpepple | moving on... | |
| jeremy | looks like a no to me :) | |
| --- bpepple has changed the topic to: FESCO-Meeting -- Plan to get Merge Reviews finished by F9 -- all | ||
| bpepple | Ok, we set a deadline for the merge reviews to be finished by F9. Is that still reasonable? | |
| warren | Without full buy-in from Red Hat engineering to 1) help with reviews 2) make engineers responsible to respond to reviews is this possible? | |
| jeremy | if 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 ... :) | |
| notting | not sure a deadline is practical. we're going to kick out packages? | |
| caillon | and what happens when the deadline passes and we aren't done? (because that's pretty likely, sadly) | |
| bpepple | jeremy: agreed. Our past attempts to get people to help out have been pretty fruitless. | |
| nirik | yeah, I still don't see a good way to do this other than slowly. | |
| warren | A BIG HELP here would be making RH engineers responsible to actually respond to review suggestions. | |
| XulChris | bingo | |
| tibbs | Yes, that's the major barrier for me. | |
| nirik | doesn't help that after the bugzilla changes the other week everything's timestamp got reset. | |
| jeremy | I can try to beat that drum again | |
| c4chris | warren: that's my impression too | |
| poelcat | warren: is there a way to split out which reviews are dependent on Red Hat engineers? | |
| caillon | maybe we can get some funding to give out swag to those who do N number of merge reviews? | |
| warren | well, if NEEDINFO is set to a @redhat.com person? | |
| jeremy | caillon: if the board wants to fund that... :) | |
| caillon | jeremy, i can bring it up next meeting! | |
| warren | poelcat: if (Merge Review && NEEDINFO is set to a @redhat.com person) | |
| nirik | I think we need both reviewers _and_ responding redhat folks... | |
| notting | warren: that being said, querying for *who* needinfo points to is nigh impossible in bz | |
| bpepple | nirik: agreed. | |
| warren | notting, sigh | |
| tibbs | nirik: 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. | ||
| nirik | tibbs: yeah, I haven't done any in a while for that reason... hard to go thru all the trouble to get no answer. ;( | |
| poelcat | warren: send me a list and I can take to dev managers at next meeting to see what their teams can reasonably commit to | |
| caillon | how many are outstanding? | |
| jima | how about Merge Review && NEEDINFO and deal with hand-sorting the non-RH ones? | |
| tibbs | I currently have eight merge reviews stalled. | |
| warren | poelcat, this isn't a matter of a one-time list | |
| poelcat, it needs to be policy | ||
| tibbs | Sorry, eleven. | |
| warren | poelcat, responsible length of time to respond to certain types of Fedora tickets | |
| poelcat | warren: i thought we were talking about the backlog? | |
| caillon | warren, well this sort of *is* a one time list though because we aren't going to have more merge stuff in the future | |
| poelcat | warren: you are introducing a second issue | |
| nirik | I only see 551 on the new list. | |
| abadger1999 | If 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 | |
| warren | caillon, no, because new NEEDINFO will appear as more merge reviews happen | |
| * abadger1999 is half joking half serious | ||
| tibbs | abadger1999: That's just not practical, unfortunately. | |
| nirik | I have 13 stalled merge reviews. | |
| warren | poelcat, not exactly, it is the same issue | |
| tibbs | We kind of need the kernel, after all. | |
| caillon | abadger1999, if you kicked out things that don't have review, i'd not have to do firefox errata for a while ;-) | |
| jeremy | abadger1999: unfortunately, we'd also end up without a distro | |
| bpepple | caillon: doing a quick query I see 716 merge reviews. | |
| abadger1999 | caillon: Hey! Silver lining to everything :-) | |
| poelcat | warren: but if you want to solve this we have to take it to them in managable pieces :) 1) backlog 2) going forward | |
| c4chris | I'll see if I can color them red in the PackageStatus reports... | |
| jwb | so i have a question | |
| warren | poelcat, ok, sounds good | |
| jeremy | jwb: 37! | |
| jima | holy carp, i didn't realize i had stalled merge reviews :( | |
| jwb | this seems to me where FESCo should sort of step in and enforce the guidelines | |
| f13 | here, sorry | |
| XulChris | jeremy: wrong, its 42 | |
| caillon | which base? | |
| abadger1999 | jeremy: 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.</> | |
| c4chris | I don't see where we have a large stick to wield... | |
| nirik | well, it's hard to enforce. I suppose we could orphan a package that has a maintainer that isn't answering merge reviews... | |
| jwb | so why can't we appoint some people, grant them cvsadmin access, and fix most of the smaller issues | |
| ? | ||
| jeremy | jwb: I wouldn't be against something like that | |
| bpepple | jwb: I don't have problem with that. | |
| nirik | how about this one: no updates to a package that hasn't passed merge review (for devel) | |
| jwb | i think if it's going to get done by F9, that's what it will take | |
| c4chris | jwb: interesting idea | |
| I kinda like it :) | ||
| jwb | we have a governing body for a reason :) | |
| bpepple | jwb: how big of a team are you thinking? | |
| warren | jwb, some RH engineers will go ballistic | |
| f13 | warren: I don't care. | |
| jwb | warren, i know. that is where jeremy and f13 will have to come in | |
| EvilBob | as long as they don't go postal | |
| nirik | well, 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? | |
| warren | f13, I don't either, I was just commenting =) | |
| caillon | jwb, note that legislative is not executive :) | |
| jwb | bpepple, i'd look for volunteers first. people FESCo trusts | |
| jeremy | jwb: 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 | |
| abadger1999 | Do 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? | |
| bpepple | jeremy: +1 | |
| jwb | jeremy, yes agreed | |
| jeremy | just like anyone who's upset that I rebuilt their package for openssl or openldap ;) | |
| bpepple | abadger1999: I don't think we have any way to determine that number easily. | |
| tibbs | There is the possibility of janitors just cleaning up the packages. | |
| dgilmore | nirik: its easy to enforce | |
| nirik: releng blocks anything that hasnt passed review | ||
| jwb | tibbs, to be honest, i like the idea of janitors in general | |
| dgilmore | nirik: people cry and get it fixed | |
| jwb | tibbs, for more than just merge reviews. people to actively go over the specs and submit patches to adapt to updated guidelines, etc | |
| tibbs | There'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. | |
| abadger1999 | nirik: 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.... | |
| bpepple | Proposal: FESCo appoints some people, grants them cvsadmin access to fix merge review packages that haven't had responded to. | |
| c4chris | bpepple: I'd be fine with that | |
| caillon | i kinda like the idea of submitting patches, actually | |
| jima | ugh, my stalled review is pathetically trivial stuff. | |
| tibbs | But what if I submit patches and they're ignored? | |
| dgilmore | bpepple: im somewhat ok withthat. there is no way to enforce that the changes stick | |
| jima | bpepple: side note: there's some precident for the access (see sparc sig) | |
| tibbs | I took to submitting patches for my merge reviews because I found it actually simpler than describing the changes. | |
| notting | don't see how that's any different from the normal 'stalled' case | |
| f13 | caillon: 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) | ||
| caillon | tibbs, then nonresponsive maintainer process kicks in? | |
| tibbs | I don't know how that process works for Red Hat employees. | |
| nirik | so this mandate would be to fix the package to pass review? or just minor things? or ? | |
| tibbs | If we only had a hundred packages left, a mandate would be something to think about. | |
| f13 | tibbs: the process should work as is. $employees manager will likely get a rude wakeup call when the package gets orphaned | |
| jwb | on a bright note, i believe the kernel already conforms | |
| bpepple | nirik: I would think for items to pass review. | |
| jwb | so at least people will still be able to boot :) | |
| tibbs | Yes, 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. | ||
| nirik | ok, 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. | |
| abadger1999 | jwb: What about grub? ;-) | |
| jwb | abadger1999, i use yaboot. don't care ;) | |
| tibbs | But does setting NEEDINFO actually do anything useful? Does bugzilla pester people to respond? | |
| nirik | how about as a show of force, everyone in fesco pledges to do 2 merge reviews before the next meeting. ;) | |
| jima | tibbs: it sends one more email, iirc | |
| jeremy | tibbs: it sends mail. but there's lots of bug mail | |
| tibbs | So chances are, any ticket sitting in needinfo isn't being actively ignored, it's just dropped through the cracks. | |
| f13 | it still shows up in mybugzilla front page | |
| c4chris | I sure hope so | |
| f13 | but 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 | ||
| caillon | it really is amazing that we get fedora stuff done | |
| bpepple | ok, so where are we on this? | |
| poelcat | so do we need a different/better nagging mechanism? | |
| c4chris | so, to summarize, we could: 1. orphan 2. cvsadmin 3. bz pester 4. do nothing ? | |
| poelcat | or is that solving the wrong problem | |
| tibbs | Can we try to set an "open merge review target" for F9? And perhaps pick a set of packages that we want to see reviewed? | |
| f13 | poelcat: I thikn that's solving the wrong problem. | |
| nirik | part of the problem is also lack of reviewers... the bulk of them left is in NEW... | |
| nirik | of course getting the stalled ones moving will make reviewers more likely to review more. | |
| f13 | poelcat: 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 | |
| caillon | and the rather daunting review process | |
| XulChris | reviews should not be rushed, i think deadlines are bad, but package maintainers need to put merge reviews at a higher priority, thats all | |
| tibbs | nirik: Yes, that's my issue. | |
| poelcat | f13: that is the missing piece IMHO | |
| f13 | poelcat: 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. | |
| caillon | maybe it's easy for the seasoned reviewer, but it's really fricken hard if you're not reviewing packages all the time | |
| jwb | caillon, i sadly agree | |
| nirik | caillon: yeah, it could be made more streamlined for sure. ;( | |
| caillon | honestly, i think that fixing the review process will help us get more reviews done | |
| f13 | but I don't tink that can be done in time | |
| warren | Asking 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. | |
| f13 | we'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...) | ||
| warren | f13, humanoid hours | |
| jwb | or eunic | |
| nirik | so 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 | ||
| XulChris | i reiterate that deadlines and rushing reviews is a bad idea | |
| nirik | then hopefully things will get better on reviews and we can get more of the smaller packages done in the next cycle? | |
| dgilmore | poelcat: :) | |
| jeremy | poelcat: that sounds like a good thing to target | |
| jwb | poelcat, good | |
| f13 | poelcat: works for me. | |
| dgilmore | f13: lifeform hours :) | |
| tibbs | Now I just hope I can make it to fudcon. | |
| nirik | well, it just needs more automation, right? | |
| f13 | dgilmore: but I have a robot do most of my work... | |
| jwb | grr | |
| dgilmore | f13: it is humanoid? | |
| jeremy | nirik: sounds reasonable. do you want to come up with a concrete proposal for what the target is, etc? :) | |
| jwb | on track people | |
| f13 | yes. | |
| XulChris | a graphical GUI review wizard would be neat | |
| warren | f13, the real jesse playing Wii now? | |
| dgilmore | f13: i think that clasifies as lifeform | |
| warren | sentient entity hours | |
| nirik | jeremy: I could try... or tibbs? you want to come up with a list of likely ones? | |
| poelcat | in 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 | |
| tibbs | Obviously kernel, X, the base utilities. | |
| nirik | rpm is done except for a license review. | |
| tibbs | I did a bunch of X already, and ajax was nice enough to say "commit whatever changes you want". | |
| warren | poelcat, I put forward these suggestions about halfway through F8 cycle just to warn them that this was coming. | |
| caillon | how many of the ones awaiting review are in the default install? | |
| dgilmore | has anyone touched glibc and gcc yet? | |
| * tibbs scared | ||
| jwb | glibc should be reasonable | |
| as should gcc | ||
| warren | Jarod did a great job making kernel.spec more reasonable | |
| jima | tibbs: wow, nice of ajax | |
| f13 | ajax is very reasonable and a great guy | |
| tibbs | jwb: The glibc spec is over 4K lines. | |
| poelcat | warren: yes, but it needs to be a "request" not a "suggestion" this time :) | |
| jwb | tibbs, i meant from a maintainer interaction perspective | |
| nirik | glibc is waiting. I think someone looked at gcc. | |
| jwb | jakub owns both | |
| dgilmore | jwb: glibc and gcc are going to be painful | |
| warren | poelcat, it was a request | |
| jwb | well, jakub and roland are fairly reasonable people | |
| painful, but not insurmountable | ||
| f13 | glibc/gcc are likely going to be a pile of exceptions to our guidelines, just because they're /odd/ packages. | |
| tibbs | That's true. | |
| poelcat | warren: can you send me the email? | |
| f13 | which I'm fine with | |
| warren | poelcat, it wasn't in e-mail, it was in meetings. | |
| tibbs | But even the kernel came into line, and I don't think anyone disagrees that it's better now for all involved. | |
| nirik | gcc has had some guideline issues... it's not really under review. | |
| warren | Let's not get all hung up on a small # of packages | |
| bpepple | ok, 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 | ||
| tibbs | bpepple: +1 | |
| nirik | ok. | |
| c4chris | bpepple: +1 | |
| bpepple | alright, 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 | ||
| c4chris | +1 | |
| bpepple | +1 | |
| caillon | (what does a +1/0/-1 mean for features again?) | |
| tibbs | There's a whole lot of stuff there; is there really a chance that it's going to be done? | |
| dgilmore | +1 | |
| 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 | |
| dgilmore | tibbs: it does seem like alot of things | |
| f13 | caillon: "accepted" as something the project wants to see happen and will advertise it and help ensure it happens. | |
| nirik | I'd really like to see headsets work out of the box, and it would be cool to have the ps3 controller working. ;) +1 | |
| f13 | caillon: making sure that it's not something stupid/illegal like "include mp3 support" or "include an image of windows" | |
| jwb | +1 | |
| f13 | caillon: just to keep some buffer between proposed features and the accepted features that press will pick up | |
| jwb | this is something we touted as a feature in F8 as well | |
| nirik | yeah, if the feature owner could weed down to whats really targeted for f9 that would be great... or note that it all is. | |
| caillon | ok. | |
| +1 | ||
| f13 | caillon: and to help us keep a handle on how many "features" we "missed" for a release. | |
| dgilmore | nirik: i want dun to work though i think i need to slap blackberry for that | |
| tibbs | By all means, though, +1 and more power to them. But I have doubts that this is all implementable before we freeze. | |
| caillon | tibbs, so the page gets re-written then | |
| poelcat | in 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 ;-) | |
| f13 | that's fine. | |
| poelcat | fork as in move unfinished stuff to f10 | |
| f13 | this is one of those cumulative improvement things. | |
| caillon | f13, yep | |
| f13 | caillon: 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 | |
| poelcat | caillon: we already voted on the feature process for f9 :) | |
| bpepple | poelcat: ok, I see seven '+1' on this, so the Bluetooth feature has been approved. | |
| jwb | again | |
| --- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Releases/FeatureClockApplet | ||
| jwb | +1 | |
| i'm using this right now and love it | ||
| bpepple | +1, looks cool. | |
| c4chris | +1 | |
| warren | +1 | |
| caillon | +1 | |
| f13 | +1 | |
| nirik | +1 | |
| poelcat | looks like 7 +1s ... moving on | |
| --- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/PartitionResizing | ||
| caillon | +1 | |
| notting | +1 | |
| c4chris | +1 | |
| jwb | +1 | |
| bpepple | +1 | |
| tibbs | +1 | |
| * jeremy abstains as the person writing code | ||
| f13 | +100 | |
| poelcat | looks like 700 +1s ... moving on | |
| --- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/VirtStorage | ||
| c4chris | f13: you used up all your voting points ... ;) | |
| * poelcat wrongly used "*" instead of "+" | ||
| jeremy | +1 | |
| bpepple | +1 | |
| c4chris | +1 | |
| notting | +1 | |
| dgilmore | +1 | |
| tibbs | +1 | |
| caillon | +1 | |
| nirik | +1 good stuff... | |
| --- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Releases/FeatureFingerprint | ||
| notting | +1 | |
| f13 | +1 | |
| jeremy | +100 | |
| f13 | for the last one, +1 for this one | |
| make my fingerprinting better! | ||
| bpepple | +1, wishes he had a fingerprint reader on his lappy. :( | |
| tibbs | +1 | |
| jwb | does fprint replace thinkfinger? | |
| dgilmore | +1 | |
| caillon | jwb, yes | |
| f13 | I do believe so | |
| c4chris | +1 | |
| jwb | +1 | |
| warren | +1 | |
| caillon | +1 | |
| nirik | +1, but note that it would be nice if they don't only do gnome work... kde/xfce want fingerprints too | |
| f13 | if nothing else, stop doing an extra newline when sudo envokes thinkfinger stuff. | |
| jeremy | jwb: that's the idea | |
| f13 | sudo yum foo always gets a "no" due ot an extra endline | |
| --- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/PackageKit | ||
| caillon | f13, not always for me | |
| +1 | ||
| * jeremy thinks that promoting two different package management frameworks is utter insanity | ||
| f13 | caillon: I get it every single time I sudo for the first time, where it would prompt. | |
| dgilmore | +1 | |
| tibbs | +1 packagekit | |
| bpepple | +1 | |
| jeremy | -1 | |
| jwb | i have no idea what packagekit will even do | |
| warren | I would vote +1 if we get to try it and change our mind later. | |
| c4chris | I'm a bit uneasy about that one... | |
| nirik | doesn't it use yum/rpm as a backend? | |
| tibbs | Yes. | |
| nirik | so it's just a spiffy new frontend? | |
| notting | unlike smart, apt, etc. it's still using yum. so +1 from me | |
| jeremy | warren: 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 | |
| warren | jeremy, what is the other stuff in parallel? | |
| f13 | nirik: not quite. | |
| jwb | is it supposed to replace pirut/pup? | |
| jeremy | warren: pirut, pup, etc. you know, the toolset that we've been working on | |
| warren | jeremy, survival of the fittest... | |
| f13 | nirik: there is a /scary/ amount of "backend" code for yum in packagekit, which has lots of potential for thigns to go wrong. | |
| nirik | hum. Is it available in f8 as well? or just rawhide? | |
| f13 | and bizarre things like hardcoded grouplistings | |
| nirik: I think just rawhide | ||
| c4chris | I'm fine to have it in Fedora, I'm just uneasy to tout it as a feature that folks should try out... | |
| jwb | warren, then you'd have to promote pirut/pup as a feature | |
| caillon | meanwhile other distros will | |
| * nirik nods at c4chris. | ||
| warren | I 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. | |
| jeremy | it'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 | |
| caillon | and 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 | ||
| warren | Let's give them a chance. | |
| jwb | notting, so it's like libvirt, but for package managers? | |
| jeremy | notting: sure we do! everyone can use apt! | |
| notting | if libvirt were only proddable via dbus... yeah, sort of. | |
| EvilBob | just 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. | |
| jeremy | notting: or they can use smart. both are available for lots of package managers | |
| tibbs | We don't have to approve this now. | |
| jwb | notting, i meant it's abstraction API? | |
| c4chris | can we punt this one 'til next week please ? | |
| caillon | jwb, parly yes. it also ships with a gnome gui (and there's a kde one that others are working on) | |
| bpepple | c4chris: +1. | |
| notting | jeremy: and you're objecting to it on the grounds of pirut/pup which... don't. | |
| dgilmore | caillon: i know there is a qt4 based on out there | |
| jwb | erm... i vote to delay voting | |
| nirik | yeah, I would like to go look at it... next week sounds good to me. | |
| caillon | so 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? | ||
| f13 | caillon: pretty much yea. | |
| bpepple | caillon: I agree. | |
| caillon | if 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 | |
| f13 | toss 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 ? | ||
| nirik | I would kinda like to look at it more, but I guess +1 | |
| f13 | and it's going to make adding features to yum that much harder, if we're comitting to keeping PK working. | |
| c4chris | 0 | |
| jwb | 0 | |
| poelcat | anything else on PackageKit? | |
| notting | f13: we break yum-utils and yumex all the time. why is this different? | |
| bpepple | poelcat: I don't think so. | |
| EvilBob | IMO 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 | ||
| jeremy | notting: because we never said that yumex was a feature of the release. nor yum-utils. | |
| skvidal | EvilBob: umm, it never works that way | |
| poelcat | jeremy: that was before the feature process ;-) | |
| notting | jeremy: 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 | |
| c4chris | +1 | |
| 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 | |
| nirik | +1 | |
| jwb | has davej agreed to carry patches for it? | |
| f13 | +1 for ext/me waits for page to load. | |
| notting | jeremy: also, yum-utils is a default package :P | |
| warren | notting, you don't have exobyte arrays at home? | |
| tibbs | +1 ext4 | |
| I definitely want larger thatn 8TB support; I hit that often enough now. | ||
| jeremy | ext4 isn't loading, but sure! although how visible it's going to be is still up in the air | |
| jwb | has davej agreed to carry patches for it? | |
| dgilmore | +1 | |
| tibbs | It'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" | |
| jwb | tibbs, with patches, yes. and since f9 is a -rc kernel, that's fine | |
| dgilmore | tibbs: your a storage anomoally | |
| jeremy | jwb: yeah. sandeen is staying on top of making sure they don't break compiling | |
| jwb | jeremy, ok | |
| --- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Releases/FeatureTexLive | ||
| tibbs | 8TB is only 9 drives these days. | |
| c4chris | very large data is coming real fast in genomics... | |
| bpepple | +1 | |
| c4chris | +1 | |
| warren | +1 | |
| caillon | +1 | |
| jwb | +1 | |
| tibbs | Finally the reviews are completed. Now we just need to get things to a nonbroken state. | |
| +1 | ||
| * jwb is a kernel geek | ||
| jeremy | +1 to texlive | |
| notting | +whatever, it already landed. | |
| nirik | +1 | |
| * poelcat counts majority == yes | ||
| f13 | +1 | |
| tetex was blocked today. | ||
| poelcat | shall we stop here for this week or knock out the last two today? | |
| tibbs | I have time. | |
| f13 | I have a topic | |
| FC6 EOL | ||
| jwb | KILL IT DEAD | |
| f13 | it's tomorrow. | |
| * nirik cheers! | ||
| EvilBob | f13: +1000 | |
| f13 | releng has a plan for what we need tod o releng wise | |
| not sure what needs to happen wiki wise | ||
| bpepple | poelcat: how about we punt them to next week? | |
| jwb | we do? | |
| f13 | and a lingering question regarding bugzilla. | |
| jwb: I posted to rel-eng@fp.o | ||
| poelcat | bpepple: okay | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| warren | Extras is finally dead | |
| bpepple | poelcat: thanks. | |
| * lmacken can't wait to kill the original updates system | ||
| f13 | lmacken: me too | |
| tibbs | But we can't get rid of plague yes.. | |
| f13 | let me dump the releng tasks | |
| tibbs | yet. | |
| caillon | lmacken, hey don't knock the old system | |
| bpepple | tibbs: right, isn't it used for EPEL still. | |
| f13 | Disable 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 | ||
| lmacken | caillon: i wrote it.. I can knock it :) | |
| f13 | Turn off the Extras sync cron job internally | |
| Disable/remove the bugzilla version? | ||
| Announce the end of life. | ||
| caillon | lmacken, it works better than bodhi for me :p | |
| f13 | Disable the updates cleaner. | |
| warren | f13, can I add one thing? | |
| f13 | warren: that's why I brought it up here | |
| warren | f13, after last push, let's be sure we didn't add a terrible new broken dep. | |
| f13 | warren: sounds great, when will you have the report in? | |
| warren | that's all. | |
| f13 | there are currently no broken deps detectable in the push tool for Core 6, I have no idea what Extras looks like | |
| dgilmore | i will be stopping extras builds on friday morning | |
| bpepple | dgilmore: cool. | |
| * nirik is sad that Xfce 4.4.2 didn't come out sonner, could have pushed it to fe6. Oh well, tough luck. | ||
| notting | surely Zod is not being EOLd, only relegated to the Phantom Zone? | |
| f13 | Can someone volunteer to trawl the wiki for FC6 mentions and fix 'em? | |
| lmacken | caillon: if by "works better" you mean "doesn't care about anything", then yeah :) | |
| bpepple | f13: I can work on that. I'll have some free time tomorrow. | |
| EvilBob | bpepple: I will help out also | |
| bpepple | EvilBob: thanks. | |
| anything else? or should we wrap up for this week? | ||
| f13 | rock! | |
| c4chris | wrap++ | |
| * 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!