| --- notting_ has changed the topic to: FESCo meeting - Init process | ||
| * nirik is here. | ||
| sharkcz here | ||
| * bpepple is here. | ||
| notting_ | jwb: dwmw2: nirik: dgilmore: sharkcz: bpepple: j-rod: jds2001: ping | |
|---|---|---|
| * j-rod here, but need to run down to the caf and grab some food real quick -- back in ~10 | ||
| nirik | sharkcz: you are on the hook for minutes this time I think. ;) | |
| sharkcz | sharkcz: I'm aware of it | |
| * dgilmore is here | ||
| * abadger1999 sits in the back | ||
| nirik | shall we get started? we have a titanic docket. ;) | |
| sharkcz | notting: I think we can start, 6 people here including j-rod | |
| notting | sharkcz: thx, i got netsplit | |
| bpepple | nirik: I think the odds of getting through it all are pretty low. | |
| j-rod | back | |
| notting | given the closeness to feature freeze, should start there | |
| nirik | bpepple: agreed. | |
| bpepple | notting: agreed. | |
| sharkcz | +1 | |
| --- notting has changed the topic to: MinimalPlatform - http://fedoraproject.org/wiki/Features/MinimalPlatform - https://fedorahosted.org/fesco/ticket/66 | ||
| notting | this is a holdover from last week | |
| bpepple | we were waiting for some input from the anaconda folks weren't we? | |
| notting | sgrubb: the last i heard, the positioning of this for F11 is just to change the 'core' comps group, and not worry as much about anaconda changes, correct? is it possible to get the feature page updated along those lines? | |
| sgrubb | Yes, correct | |
| I suppose it could be updated. Does it need updating today? | ||
| I believe wrabco is off for the weekend | ||
| bpepple | I think if you update before the feature freeze that should be ok. | |
| sgrubb | does it need to be updated to be approved? | |
| * bpepple is fine with approving the feature with the knowledge that the anaconda bits will be removed from the feature page. | ||
| * notting is +1 too | ||
| sharkcz is +1 | ||
| sgrubb | ok, thanks | |
| j-rod | so wait... did we determine this minimal set would be the same minimal set that anaconda would install in text mode? | |
| and thus its basically just a case of making sure the required packages are in the right comps groups? | ||
| sgrubb | I thought it was said on the bz that deselecting all groups yeilds a minimal install | |
| it wasn't specified that you must be in text mode | ||
| * nirik is +1 on this, but yeah, would be good to clarify from anaconda folks if this means core is what you get in text mode. | ||
| j-rod | the new anaconda text mode does a 'minimal install', just trying to understand if that is the same 'minimal install' | |
| regardless of gui mode or text mode, just trying to determine if all 'minimal installs' are the same or not | ||
| * dgilmore thinksin minimal set should be yum bash and openssh | ||
| notting | (back in a couple min, sorry) | |
| sgrubb | sort of...the minimal install is missing a couple things and thus we want to expand the core by a few packages | |
| dgilmore | sgrubb: acpid is gone right? | |
| kanarip | j-rod, iirc, the minimum install in the anaconda case is @core and @base | |
| sgrubb | yes | |
| j-rod | sgrubb: but they'll go into a comps group, such that your minimal install == the anaconda minimal install, correct? | |
| dgilmore | j-rod: i agree minimal should be the same regardless of install method | |
| j-rod | dgilmore: and I'd love it if 'minimal install' really was as minimal as you suggested too. :) | |
| nirik | thats what it will be right? at least according to https://bugzilla.redhat.com/show_bug.cgi?id=485995 | |
| * j-rod wonders if we need 'minimal' and 'really minimal' installs... | ||
| bpepple | j-rod: ;) | |
| sgrubb | j-rod, but that doesn't yeild a complete "system" | |
| for example, no iptables | ||
| j-rod | sgrubb: no, but it gives enough to add whatever you need | |
| bpepple | didn't we have this same argument last week? | |
| nirik | so, net effect here is core is growing sudo/audit/cronie/openssh-server/iptables ? | |
| dgilmore | j-rod: perhaps minmal text and minimal X installes | |
| sharkcz | so rather call it "basic" install instead of "minimal"? | |
| * nirik sees the clock ticking here. | ||
| sgrubb | j-rod, the user experience we are after is that you can easily select a minimal working system | |
| dgilmore | sgrubb: thats impossible | |
| sgrubb | that is secure and maintainable | |
| j-rod | whatever, so long as there's only *one* minimal install that is the same everywhere | |
| nirik | sgrubb: could you re-write the feature page and we can look at it in a special session which I know we will have to have before freeze? | |
| sgrubb | dgilmore, its not impossible | |
| j-rod | what should be in it can be debated ad infinitum | |
| dgilmore | sgrubb: it is. because it means something else to different people | |
| sgrubb | nirik, sure, it won't be today, though. | |
| nirik | ok. I vote we look at this at a later special session before tuesday and move on for now. | |
| notting | j-rod: right now, the text mode package set you get is core + base | |
| i.e., bigger than this | ||
| j-rod | narf. | |
| notting | poit! | |
| j-rod | so we do have two different "minimal" installs. bleah. | |
| notting | we can always change the anaconda one | |
| j-rod | yeah, I'd say change the anaconda text mode one to be just as minimal | |
| sgrubb | why not both? | |
| notting | sgrubb: not sure what you mean? | |
| j-rod | both what? | |
| sgrubb | someone said gui mode vs text mode leaves you with 2 different minimal installs | |
| notting | sgrubb: anaconda in f11 changed so that text mode doesn't have package selection. the currently hardcoded defaults are different than the new proposed minimal install | |
| notting | so i suggested syncing the two | |
| j-rod | end user: "I did a minimal install" | |
| now you have to go back and figure out *which* minimal install | ||
| sgrubb | notting, ok, sure | |
| dgilmore | notting: i dont agree with the text mode changes. but i agree that they should be the same | |
| notting | dgilmore: noted, but whether or not text mode should have package selection is out of scope for this discussion | |
| dgilmore | notting: sure | |
| notting | so, with feature page being updated to denote that this is a comps change + flipping the anaconda text default to match it... i'm reiterating my +1. other votes? | |
| bpepple | +1 | |
| sharkcz | +1 | |
| nirik | +1 | |
| dgilmore | -1 | |
| I think that for minimal the package set is too big | ||
| * abadger1999 notes we've reached 30 minutes. | ||
| bpepple | abadger1999: yeah, at this rate we'll get through 4 features. :( | |
| notting | dwmw2 & jds aren't here. j-rod: opinon? | |
| j-rod | +1, so long as we get all minimals the same | |
| notting | ok, so that's 5 +1, 1 -1, 3 0. | |
| it passes. barely. | ||
| --- notting has changed the topic to: AnacondaStorageRewrite - http://fedoraproject.org/wiki/Features/AnacondaStorageRewrite | ||
| sgrubb | thanks everyone | |
| bpepple | This feature should probably be merged with the pyparted feature, imo. | |
| notting | dlehman: it was just mentioned that perhaps this should be merged with the pyparted featre? | |
| denise | pyparted is used by storage rewrite but is semi-independent and is already working w/current anaconda | |
| dlehman | notting: they are at least mostly independent, but if mergin them gains us something... | |
| bpepple | no, if there's a good reason to keep them separate I'm fine with that, but they seemed so closely related I figured I would bring it up. | |
| notting | dlehman: maybe better discussed in the pyparted review, as the anaconda one is the larger effort | |
| dlehman | notting: sounds right to me | |
| notting | dlehman: so, f11 gets the backend rewrite + frontend port to new backend, f12 gets the frontend rewrite? | |
| dlehman | notting: yes | |
| notting | "Before this code hits Rawhide it will be smoke-tested in a custom compose. ". given that, the 80% figure, and the upcoming feature freeze... is this going to make it? | |
| dlehman | we were able to introduce the full changeset using just an updates.img, so the custom compose does not gain us anything, really | |
| denise | storage test day scheduled for next thursday - would be better to submit after that if possible | |
| notting | feature freeze is tuesday. feels weird submitting features after freeze | |
| denise | agreed but would definitely be better for rawhide | |
| notting | i'm +1 to the feature. it just makes me nervous schedule-wise | |
| dlehman | we could merge to rawhide by tuesday, but it would be less stable | |
| * nirik nods. +1 here as well. I guess we can always revert. | ||
| bpepple | +1 to anaconda storage feature. | |
| * sharkcz agrees with notting +1 | ||
| dgilmore | +1 | |
| notting: and i agree | ||
| it would be good to land the f-12 features soon after F-11 is done | ||
| * dgilmore thinks we should be discussing F-12 features at this point in the schedule not F-11 ones | ||
| notting | dgilmore: AIUI, they're still talking with the interface designers for the UI part, so those may need to wait a bit | |
| nirik | dgilmore: ideally, but sometimes thats hard. | |
| j-rod | +1 | |
| notting | that's 6 +1, AnacondaStorageRewrite passes | |
| --- notting has changed the topic to: EFI - http://fedoraproject.org/wiki/Features/EFI | ||
| sharkcz | ia64 is not critical for Fedora | |
| * notting is +1 | ||
| sharkcz | +1 | |
| * notting refrains from shortening sharkcz's statement | ||
| dgilmore | +1 | |
| nirik | +1 | |
| dgilmore | i think ia64 support is up to the ia64 team that currently doesnt exist | |
| bpepple | +1 | |
| notting | that's 6 +1, counting jds's in trac. so EFI support passes | |
| --- notting has changed the topic to: IntelKMS - http://fedoraproject.org/wiki/Features/IntelKMS | ||
| bpepple | +1000 here. | |
| dgilmore | +1 its working on my T61 | |
| nirik | hurray. +1 and I hope it works better than the current f10 driver. ;) | |
| * notting is +1, although i echo jds's concern that the relnote in the feature page be fleshed out | ||
| sharkcz | +1 | |
| dgilmore | however i do have a bug i need to report | |
| for an opps i just get the plymouth boot splash | ||
| not teh opps | ||
| oops | ||
| notting | ok, that's 6 +1s, counting jds in track. IntelKMS passes | |
| --- notting has changed the topic to: NewPyParted - http://fedoraproject.org/wiki/Features/NewPyParted | ||
| nirik | is this really a feature? | |
| notting | jds2001 questioned whether this was feature-worthy in trac | |
| dgilmore | -1 i dont think its a feature | |
| nirik | no docs, no release notes, no user experence change. | |
| it's cool and worthy and nice, but I don't think it's a feature really. | ||
| notting | i would agree. sharkcz/j-rod/bpepple? | |
| j-rod | esp. not necessary w/the anaconda storage rewrite already being pimped | |
| * sharkcz agrees with nirik | ||
| denise | fine with anaconda - code is in, want me to just hook it to storage page? | |
| bpepple | -1, while cool I don't think it qualifies as a feature. | |
| dgilmore | j-rod: right. it can be a note along with the anaconda backaned changes | |
| notting | ok, that's 5 -1s to New PyParted as a feature. no objections to actually doing it, though. | |
| j-rod | yeah, I'd just make it part of the storage thing | |
| denise | ok, will do | |
| --- notting has changed the topic to: SVirt Mandatory Access Control - http://fedoraproject.org/wiki/Features/SVirt_Mandatory_Access_Control | ||
| dgilmore | i have a question | |
| I use lvm to create space for my guests | ||
| dgilmore | currently i have to put selinux in permissive mode for it to work | |
| since libvirt/qemu cant access the raw disks | ||
| how is that use case to be handled? | ||
| clalance | dgilmore: I think right now you have to change the context by hand. | |
| nirik | good question. Many people use lvm bits... would be good to include them. | |
| +1 for the svirt feature. | ||
| sharkcz | +1 | |
| j-rod | is the 30% complete part accurate? | |
| clalance | j-rod: It's a little bit low, I think. | |
| j-rod | i.e., will this actually be testable in a few days? | |
| dgilmore | clalance: i think thats something that should be done automatically if you create your lvm partition in virt-manager. perhaps even when running virt-install | |
| j-rod | +1 in general though | |
| clalance | dgilmore: Yes, agreed. | |
| j-rod: The patches were reposted to libvirt-list a few days ago. | ||
| And I think they are mostly ready to go. | ||
| dgilmore | +1, though i think its not testable for alot of people | |
| j-rod | clalance: are we carrying them in our libvirt packages already? | |
| clalance | j-rod: No, not yet. | |
| bpepple | +1 to SVirt mac feature. | |
| j-rod | ok, because by "actually testable" in a few days, I mean "this support exists in the fedora packages" :) | |
| clalance | j-rod: Yeah, I know :) | |
| Actually, let me check real quick just to make sure. | ||
| j-rod | clalance: if they aren't in... I presume they will be added in time for beta freeze? | |
| clalance | j-rod: Yeah, I believe that is the plan. | |
| j-rod | 5 +1's here so far... +1 from jds in trac | |
| I think we're all set on this one then, no? | ||
| notting | +1 from me | |
| yeah, SVirt passes | ||
| --- notting has changed the topic to: VirtVNCAuth - http://fedoraproject.org/wiki/Features/VirtVNCAuth | ||
| nirik | lots of TBD there. | |
| is the feature owner here? | ||
| clalance | The support for that has recently been reposted to qemu-devel. | |
| glommer | nirik, I'm afraid he just left. | |
| clalance | nirik: No, but I asked him earlier and he said the feature page is pretty much up-to-date. | |
| nirik | well, the how to test and release notes really need to be filled in. | |
| sharkcz | it needs updates in the "how to test" section to be useful ... | |
| notting | +1 to the concept, but how to test needs work | |
| sharkcz | +1 as notting | |
| j-rod | +1, same as above | |
| bpepple | +1 | |
| nirik | +1, please update those sections as soon as you can. | |
| notting | ok, 5 +1s. VirtVNCAuth passes with the caveat that "How to Test" and "Release Notes" need to be further filled out | |
| clalance | nirik: I'll send mail to danpb. | |
| nirik | clalance: thanks. | |
| --- notting has changed the topic to: Shared Network Interface - http://fedoraproject.org/wiki/Features/Shared_Network_Interface | ||
| notting | Current status looks... suboptimal. | |
| clalance | Heh. | |
| bpepple | yeah, is it likely to be testable by feature freeze? | |
| nirik | yeah, I have been manually using a bridged setup here for a long time, this would be great, but it doesn't look very complete yet. | |
| nirik | lutter: you around? | |
| j-rod | so this is basically just glue to make setting up a bridge easier, right? | |
| * dgilmore does this today by setting up bridging | ||
| clalance | j-rod: Yeah, basically. | |
| nirik | j-rod: yeah, without mucking with stuff manually. | |
| dgilmore | but thats not supported by NM | |
| notting | albiet a *lot* of glue | |
| clalance | j-rod: The idea, though, is so that you could also do this remotely (with lots of caveats, of course). | |
| * dgilmore thinks NM should gain the ability to say int foo is a bridge | ||
| clalance | dgilmore: That's part of the feature. | |
| dgilmore: That is, the code on the backend will be shared by libvirt and NetworkManager. | ||
| dgilmore | clalance: i spoke with scbw about it at fudcon | |
| dcbw | ||
| j-rod | so how close is any of this to being a reality right now? | |
| * dgilmore would like to see both wifi and wired devices on the bridge and have things fully transparent when moving from wireless to wired | ||
| clalance | j-rod: I'm not entirely sure, but patches to libvirt have not yet been posted. | |
| (I don't know the status of netcf itself) | ||
| notting | if 'Current status' is accurate (design, discussion, no code) i'm leery of approving for f11 | |
| j-rod | yeah, that's what I was getting at | |
| clalance | notting: I was told it's more or less accurate. | |
| dgilmore | this sounds like a great to have feature with no hope of being testable next week | |
| j-rod | netcf would still need to be packaged and go through package review within the next few days... | |
| * dgilmore says -1 punt to F-12 | ||
| j-rod | clalance: I take it you're the proxy for all things virt-related today... ;) | |
| clalance | j-rod: You got it :). | |
| dbewley | https://fedoraproject.org/wiki/FWN/LatestIssue#netcf_Network_Interface_Configuration_Library little bit here including link to git for netcf | |
| dgilmore | dbewley: it doesnt exist if its not in fedora. we cant have features testable by checking out from git and building | |
| * notting agrees with dgilmore -1 for f11 as a feature | ||
| dbewley | i'm not taking a stance, just trying to point out something that may not be on the feature page FYI | |
| lutter | nirik: now I am | |
| bpepple | -1 for F11 | |
| clalance | Ah, lutter can explain better :). | |
| lutter | dgilmore: the plan is to ad it to rawhid RSN | |
| dgilmore | lutter: you have until tuesday | |
| notting | it may be best to have netcf packaged now but delay the Feature-ing of it until F12 when it's all wired in everywhere | |
| dgilmore | is netcdf even up for review yet? | |
| netcf | ||
| lutter | dgilmore: no, it's not | |
| realistically, I might get enough done to have netcf + libvirt wired by the beta freeze | ||
| dgilmore | lutter: it needs to be packaged past review and ready for testing by wednesday | |
| j-rod | yeah, given that the lib isn't even packaged yet, I don't see how we can expect the feature to be testable by end-users by 3/10... | |
| lutter | but things like virt-manager and NW integration won't be possible by then | |
| dgilmore | so you need it doen by tuesday | |
| j-rod | i.e. -> target as a feature in F12 | |
| dgilmore | lutter: so lets make a start and punt as a feature for F-12 | |
| sharkcz | -1 for F11 | |
| lutter | dgilmore: yeah, unfortunately seems reasonable | |
| j-rod | -1 for f11 at this point, its just not ready yet, but absolutely all for it getting done | |
| notting | ok, SharedNetworkInterface is dis-approved as a feature for F11 - suggest F12. | |
| dgilmore | lutter: i definetly want to see it in :) | |
| wwoods_sick | "deferred" is a good word to use here | |
| lutter | dgilmore: as I said, I think the libvirt + netcf bits will make it | |
| --- notting has changed the topic to: EclipseProfilingTools - https://fedoraproject.org/wiki/Features/EclipseProfilingTools | ||
| dgilmore | +1 as long as we get content for release notes | |
| j-rod | +1 | |
| nirik | ok, this looks good to me, but needs release notes filled in. +1 | |
| bpepple | +1 | |
| sharkcz | +1 | |
| j-rod | aside from the release notes, a rather nicely done feature page | |
| notting | +1 | |
| 6 +1s, EclipseProfilingTools passes. Please add release notes. | ||
| --- notting has changed the topic to: Evdev2.2 - https://fedoraproject.org/wiki/Features/Evdev2.2 | ||
| * notting is +1 | ||
| nirik | +1 | |
| sharkcz | j-rod: even screenshot are there :-) | |
| notting | wrong time of day to get whot here to comment | |
| dgilmore | +1 but when is it due to be released? | |
| wwoods_sick | I've been talking to him about the input features | |
| I'll proxy a bit | ||
| Evdev 2.2 is already in Rawhide | ||
| sharkcz | +1 | |
| dgilmore | ok sto feature page needs updating | |
| wwoods_sick | or, rather, a very close pre-release | |
| notting | wwoods_sick: well, 2.1.99.git<somethingorother> | |
| wwoods_sick | right | |
| j-rod | +1 | |
| bpepple | +1 | |
| notting | ok, so 6 +1. Evdev2.2 approved,. | |
| --- notting has changed the topic to: InputDeviceProperties - https://fedoraproject.org/wiki/Features/InputDeviceProperties | ||
| wwoods_sick | same situation here - code is already in rawhide | |
| test plan was recently updated, and you can follow that to confirm this fact | ||
| nirik | +1 here. | |
| sharkcz | +1 | |
| dgilmore | +1 | |
| nirik | should we also look at dropping/eoling synaptics stuff as part of this? or are they still useful for something? | |
| wwoods_sick | this mechanism lets us configure input devices at runtime without resorting to editing FDI files *or* horrible hacks like synaptics' SHMConfig | |
| notting | +1 | |
| j-rod | +1 | |
| bpepple | +1 | |
| j-rod | nirik: there's a mention of synaptics 1.0 | |
| wwoods_sick | nirik: hold that question for the SynapticsUpdate feature | |
| heh | ||
| j-rod | which apparently uses this stuff | |
| notting | nirik: i was mentioning that to him yesterday in the context of wdaemon | |
| nirik | ah, ok. | |
| dgilmore | wwoods_sick: is there documentation/tools on configuring things | |
| notting | so, 7 +1 counting jds2001. InputDeviceProperties passes | |
| wwoods_sick | dgilmore: mostly you use the 'xinput' tool from xorg-x11-apps | |
| --- notting has changed the topic to: NouveauModesetting - https://fedoraproject.org/wiki/Features/NouveauModesetting | ||
| wwoods_sick | AFAIK to make changes permanent you can use FDI files | |
| notting | so, unlike intel/radeon, this would be available, but off by default | |
| nirik | does nouveau handle suspend/resume better than 'nv' ? | |
| wwoods_sick | nirik: that's more a question for the Nouveau-by-default feature | |
| nirik | surely. sorry. | |
| j-rod | wow. nouveau hates this machine... regardless of kms... | |
| * dgilmore has no way to test this feature | ||
| wwoods_sick | (as a side note, AFAIK nouveau *should* support suspend/resume better than nv, but I haven't tested) | |
| * j-rod just tried starting X on a gf6600-equipped box, and it started beeping incessantly at him, no video | ||
| bpepple | +1 to nouveau modesetting feature. | |
| nirik | well, +1 here for me, it's something we should mention for users that want to try it out. | |
| j-rod | but... +1 | |
| notting | +1, bravely into the future we go! | |
| * dgilmore does wonder how it can get to 100% in time for feature freeze. when it was updates to 50% today | ||
| sharkcz | can be a feature combined with "off by default"? | |
| dgilmore | +1 otherwise | |
| sharkcz: thats not a feature | ||
| j-rod | should make a note of that to the feature owner then :) | |
| sharkcz | ok, +1 | |
| j-rod | 'how to test' suggests its off by default | |
| wwoods_sick | The scope is pretty narrow; optional modesetting for one specific chipset series | |
| j-rod | oh, so does 'user experience'... | |
| wwoods_sick | yes, off by default | |
| j-rod | so its really "nouveau kms preview if you're brave" | |
| * dgilmore is thinking punt to F-12 when its useful by more people | ||
| j-rod | did we do anything along these lines for intel kms in f10? | |
| dgilmore | not that i remeber | |
| wwoods_sick | in f9 we did | |
| this was the extent of our modesetting support in f9, actually | ||
| "off-by-default optional preview for i915 if you're brave" | ||
| notting_ | but i don't think we did a feature page for it | |
| * nirik nods. | ||
| wwoods_sick | it was definitely worth it from a marketing / mindshare POV, since it led to plenty of people testing it out | |
| nirik | I don't think being off by default should preclude it as a feature... it's something we want to trumpet and ask people who are brave to test. | |
| j-rod | agree that its probably still worth it for the marketing | |
| bpepple | And to entice those brave souls. ;) | |
| j-rod | yeah, that too. :) | |
| notting | we have 6 +1, so NoveauModesetting passes. | |
| sharkcz | good marketing is required in these times ... | |
| --- notting has changed the topic to: XserverOnePointSix - https://fedoraproject.org/wiki/Features/XserverOnePointSix | ||
| j-rod | +1 | |
| bpepple | +1 no-brainer. | |
| sharkcz | +1 | |
| nirik | +1 | |
| notting | +1 | |
| so, 6 +1s (counting jds in trac), X 1.6 passes. | ||
| * j-rod wanders down the hall for a sec to grab another beverage... | ||
| --- notting has changed the topic to: VirtImprovedConsole - https://fedoraproject.org/wiki/Features/VirtImprovedConsole | ||
| dgilmore | +1 | |
| for Xserver | ||
| notting | clalance: why not qxl? | |
| nirik | does this work in virt-viewer too I hope? I see no mention of it | |
| clalance | nirik: Yes, it will work for anything that attaches to VNC. | |
| nirik | cool. | |
| clalance | nirik: It's not limited to virt-viewer, but yes, it will help virt-viewer. | |
| notting | clalance: erm, never mind :) | |
| clalance | notting: This is really cheap and easy. | |
| nirik | again, release notes must be added. | |
| +1 here. | ||
| sharkcz | +1 | |
| nirik | the not tracking mouse is very anoying, glad it will get fixed. ;) | |
| notting | +1 | |
| bpepple | +1 | |
| clalance | nirik: Yeah, me too, we've had that one for a *long* time. | |
| j-rod | how does umbongo do wide-screen kvm guests? | |
| clalance | j-rod: What's umbongo? | |
| * clalance goes to google... | ||
| j-rod | clalance: that brown distro | |
| ubuntu :) | ||
| clalance | j-rod: Ah, gotcha. | |
| j-rod: I don't know off-hand, actually. | ||
| dgilmore | +1 | |
| notting | i see 6 +1 (counting jds in trac). VirtImprovedConsole approved, please add release notes. | |
| j-rod | I only vaguely remember starting up an ubuntu live image in kvm and thinking "hey, that's neat, its wide-screen on my wide-screen" | |
| --- notting has changed the topic to: Thunderbird 3 - https://fedoraproject.org/wiki/Features/Thunderbird_3 | ||
| j-rod | +1 as well to the improved console | |
| notting | +1 from me to tbird | |
| j-rod | and +1 on tbird | |
| dgilmore | +1 please build | |
| sharkcz | +1 | |
| nirik | +1 | |
| * notting welcomes the return of "there is no turning back" | ||
| notting | that's 6 +1 to tbird (counting jds). Thunderbird3 approved. | |
| --- notting has changed the topic to: SynapticsUpdate - https://fedoraproject.org/wiki/Features/SynapticsUpdate | ||
| j-rod | yeah, nice contingency plan... :) | |
| bpepple | +1 to tb3 | |
| j-rod | +1 for the synaptics update | |
| bpepple | +1 to synaptics update | |
| sharkcz | +1 | |
| notting | +1 to synaptics. if gsynaptics isn't going to work, we may want to EOL it | |
| dgilmore | +1 | |
| nirik | yeah, +1 and we should look at eoling the frontends that only talk to the old backend. | |
| dgilmore | notting: ksynaptics will need looking at also | |
| nirik | and xfce has a synaptics panel plugin that will possibly need to die/update. | |
| notting | ok, that's 7 +1 to SynapticsUpdate. it passes. | |
| ... END OF FEATURES SECTION ... | ||
| nirik | woah. Thats all the pending features? | |
| bpepple | with 3 minutes to spare. ;) | |
| glommer | what about kvm and qemu merge? | |
| notting | so, do we go over, or do we punt non-feature items to next week? | |
| * dgilmore is ok either way | ||
| j-rod | uh-oh, what kvm and qemu merge? | |
| notting | glommer: doesn't appear to be in the ready for fesco list | |
| nirik | well, what else is on the agenda? | |
| abadger1999 | provenpackager guidelines; noarch subpackage hash check; | |
| notting | and requires.private in pkgconfig | |
| abadger1999 | CC repository I think | |
| * nirik doesn't think any of those will be very short, will they? | ||
| bpepple | nirik: I don't think so. | |
| notting | abadger1999: CC repo is punted to board | |
| j-rod | I'd say at most, work on the provenpackage reseed, punt everything else to next meeting | |
| abadger1999 | provenpackager wouldbe only if people just sayf13's proposal is good enough. | |
| nirik | I guess we can try provenpackager and see if it's easy. ;) | |
| * bpepple is/has been fine with f13's proposal. | ||
| nirik | The other alternate I had for that was a) fesco + releng are sponsors in provenpackager, or b) fesco votes on provenpackagers. | |
| abadger1999 | https://fedorahosted.org/fesco/ticket/70 | |
| nirik | and c) packagers sponsors are provenpackager sponsors. | |
| notting | for reference "f13 posted some guidelines here: http://www.mailinglistarchive.com/fedora-devel-list@redhat.com/msg70637.html" | |
| nirik | I am ok with any of a/b/c... but a/b might make rsc or others who don't like c happy. | |
| rsc_: you around and able to comment? | ||
| * notting_ likes c, but it does leave a little grey area as to what is used as criteria | ||
| j-rod | so with a)... if you leave fesco, are you a provenpackager emeritus? | |
| bpepple | j-rod: in general, we've never revoked privileges for past FESCo members unless they asked to. | |
| j-rod | worksforme | |
| * dgilmore likes C | ||
| j-rod | so with a) or b), there isn't a way for anyone but a new fesco or releng person to gain sponsor power | |
| j-rod | not sure if that's good or bad | |
| notting | fyi, if we don't wrap this up soon, i'm going to have to bail out | |
| j-rod | I should know this... but how many people are sponsors right now? | |
| notting | (i don't want to cut short discussion, just stating this) | |
| notting_ notting | ||
| nirik | 78 last I checked. | |
| notting_ notting | ||
| perhaps we should punt another week? | ||
| j-rod | and in c), would a new sponsor also gain provenpackager sponsor status? | |
| bpepple | notting: I've also got to get going fairly soon. | |
| nirik | I guess I can post those proposals on the list? | |
| j-rod | are we all good w/f13's proposal at least? | |
| dgilmore | j-rod: id say no | |
| j-rod: packager sponsors remain the ones to sponsor | ||
| notting | ok, then i think we'll move discussion to the list and table votes until next week? | |
| dgilmore | by being in provenpackager you dont automatically become a sponsor | |
| notting: ok | ||
| bpepple | yeah, probably for the best instead of rushing some decision. | |
| j-rod | dgilmore: sorry, no, I meant "if you become a sponsor, are you also a provenpackager and/or a provenpackager sponsor" | |
| dgilmore | j-rod: yes | |
| notting | anyone else have agenda items they'd like to raise? | |
| j-rod | so yeah, ship the options to the list w/some broader explanations, I think | |
| all set here | ||
| dgilmore | j-rod: since we trust you with sponsoring packages you should know what your talking about at a level that lets you do the same for provenpackager | |
| notting | if not .... | |
| * notting will close the meeting in 30 ... | ||
| * notting will close the meeting in 15 ... | ||
| notting | ... end of meeting. Thanks all. | |
| notting_ notting | ||
| bpepple | notting: thanks! | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!