| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| herlo | blah blah blah | |
|---|---|---|
| bpepple | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod | |
| Hi everybody; who's around? | ||
| * nirik is here | ||
| Kick__ is here | ||
| bpepple | sadmac2: you about? | |
| * jwb is here | ||
| j-rod here | ||
| sadmac2 | yo | |
| nirik | I do have to leave for an appointment in about 40min however... so I will have to miss out on the latter part of the meeting. | |
| * jeremy is sitting in the cheap seats | ||
| * jds2001 somewhat here | ||
| warren | who is kick? | |
| jds2001 | $DAYJOB being demanding today | |
| Kick__ | Karsten | |
| jds2001 | warren: Karsten | |
| bpepple | sadmac2: while we are waiting for the rest of FESCo to show up, do you want to start on you upstart update? | |
| * jwb hands warren a /whois | ||
| --- bpepple has changed the topic to: FESCo-Meeting -- Upstart status report - sadmac2 | ||
| sadmac2 | Keybuk: are you here as well? | |
| (Upstream is supposed to attend as well) | ||
| but anyway | ||
| sadmac2 | So, Upstart 0.5 was just recently released | |
| Keybuk | I am | |
| sadmac2 | goot | |
| sadmac2 | This new release is one we've been blocking on for awhile. There's quite a bit new in it | |
| * dgilmore is here | ||
| sadmac2 | Now we had stated that 0.5 would be when we would begin converting large parts of the system to the "upstart way of doing things" | |
| however, it turns out that the part in quotes has run into some issues | ||
| dgilmore | sadmac2: why? | |
| sadmac2 | Keybuk has pointed out, rightly, several very core use cases, pertaining to the mounting of file systems, instance jobs, etc, which are poorly served by current Upstart, and by most enhancements thereto | |
| now, what we have currently could quite well work for many of the later processes | ||
| but it has been the opinion of upstream that the event model has begun to show serious weakness | ||
| Keybuk | I wouldn't say the model doesn't work, I'd say the implementation and expression doesn't work ;) | |
| nirik | it's quite late in the cycle to be making lots of changes like that isn't it? so this will all need to wait for next cycle? | |
| sadmac2 | nirik: that's what we're getting at | |
| Its looking like Upstart is going to need to change substantially to solve the problem it was designed for | ||
| I'm Ok with this. Even in pure sysv mode Upstart is serving Fedora just fine. | ||
| bpepple | sadmac2: does this effect some of the other features like 30second startup? | |
| dgilmore | sadmac2: nice | |
| sadmac2 | bpepple: the 30 second startup proposal was made independent of me. you'll have to ask the proposers | |
| bpepple | sadmac2: ok. | |
| jds2001 | sadmac2: will this work be done in time for F11 you think? | |
| Keybuk: ^^ | ||
| sadmac2 | jds2001: I tend to overestimate deadlines for safety :) If we can get the new design laid out firmly, I am willing to work full tilt on the code modifications | |
| Keybuk | jds2001: I don't have any timescales at this point | |
| I doubt work will begin until after LPC | ||
| so F12 | ||
| (since I expect you'd want to land the completed version at the earliest point in your cycle, rather than right before release) | ||
| jds2001 | right | |
| Keybuk | 0.5.x will be supported for at least the next 18 months anyway :) | |
| stickster | Keybuk: Good point. | |
| bpepple | Keybuk: definitely. | |
| j-rod | um, wait, we target stuff that' | |
| bpepple | anyone have any other questions in regard to upstart? | |
| j-rod | that'll be completed just in time all the time | |
| Keybuk | and to me, it seems better to bed in 0.5 and understand any problems better before rushing off and fixing problems we're only theorising about at this point | |
| j-rod | but whatever. my system boots, and I usually just suspend/resume anyway... :) | |
| nirik | I think at this point all we need to say is that we will stick with the current setup for f10, and work can be ongoing to see what the f11/f12 solution is. | |
| bpepple | j-rod: same here. ;) | |
| nirik: agreed. | ||
| j-rod | nirik: yeah, agreement here too | |
| jds2001 | nirik: +1 here | |
| ion_ | nirik: Agreed. | |
| bpepple | ok, if there is nothing else, we should probably move on since we've got a lot on the schedule for today. | |
| * nirik does appreciate the info tho... would love to have more of this kind of feedback to fesco from other major components... ;) | ||
| sadmac2 | bpepple: I'm done if | |
| sadmac2 | nobody else has anything | |
| bpepple | sadmac2, Keybuk: thanks for the update on upstart. | |
| sadmac2 | np | |
| bpepple | moving on...... | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Revert curl change made for flash - jwb | ||
| bpepple | jwb or warren want to lead on this? | |
| dgilmore | bpepple: i will | |
| warren | spot: you here? | |
| bpepple | dgilmore: floors yours. | |
| dgilmore | so spot added a second soname file to curl | |
| to me this seems wrong | ||
| drago01 | no its not | |
| because the api did not change | ||
| f13 | drago01: please let dgilmore finish. | |
| dgilmore | it should be in a compat package if at all | |
| drago01 | f13: ok | |
| * nirik suggests we put a timelimit on this non issue, so we can get to other business without taking up the entire meeting. | ||
| dgilmore | regardless of why it was done it was done in the wrong way | |
| there is 2 issues here | ||
| one is that its should have been in a -compat package | ||
| the other is that the only user right now is flash | ||
| warren | I would say it is clearly unusual, but it is unclear if it is technically wrong. Both sonames are actually the same ABI, and this is what Debian has been doing for a long time now after they realized that the soname bump was an upstream mistake. It seems that we have no written guidelines actually forbidding this. | |
| dgilmore | warren: since when have we followed the debian way | |
| warren | That is an irrelevant question, mentioning of Debian was only to show that others realized the same mistake. | |
| The key question we have to ask ourselves is, is this actually technically wrong and against our guidelines? I would asset that it isn't. | ||
| assert* | ||
| dgilmore | to me it seems if we do this then it should be in a compat package | |
| mjg59 | The issue with providing a compat package in this case is that it's either a new source package (which would be identical to the existing one, except that the soname of the library would be changed) or it'd be a sbupackage of the existing source that provides nothing but a tiny file | |
| * j-rod says put it in a -compat sub-package and move along | ||
| mclasen | if the abi did not acutally change, why not just patch it to stay with the old soname ? | |
| dgilmore | mjg59: there is nothing to say that the -compat cant come out of the same source rpm | |
| mjg59 | The existing cases where we provide compat packages are when the functionality of the two package versions is incompatibly different. | |
| jwb | should we vote on j-rod's proposal? | |
| jds2001 | mclasen: lots of stuff built with new soname | |
| nirik | mclasen: we already rebuilt everything with the new so | |
| dgilmore | mclasen: we have rebuilt everything against the new soname | |
| Kick__ | -1, I'd rather have a 2k wrapper file in libcurl or a libcurl subpackage then having a 2k compat package or even worse a full compat-libcurl with just the soname change | |
| warren | The compat sub-package suggestion to me seems just a naive "I don't really care but this seems right." solution, however it doesn't actually change anything, while introduces more inconvenience for a package that quite literally contains a ~2600 byte file. | |
| mjg59 | dgilmore: Sure, but at that point you have an additional binary package (and associated overhead) for the single purpose of providing something that's effectively a symlink | |
| nirik | jwb: if that will make everyone happy, I am all for it. | |
| nirik | +1 j-rods proposal of a compat subpackage. | |
| warren | please wait a moment | |
| j-rod | I think a -compat sub-package is the best compromise between the two extremes | |
| dgilmore | mjg59: we have always used -compat packages to provide different sonames of the same thing | |
| warren | what exactly does a compat subpackage help? | |
| mjg59 | dgilmore: Yes, because in those cases they provide incompatible ABIs | |
| jwb | wait | |
| wait wait wait | ||
| mjg59 | dgilmore: They're two different situations. Treating them differently doesn't create any incompatibility. | |
| drago01 | what exactly is the problem with the ~2k file in curl? maintaince overhead is ~0 ... | |
| dgilmore | warren: because if i have nothing that requires it i save some space. useful for resource contrained machines | |
| sadmac2 | dgilmore: the file is literally empty | |
| dgilmore: well, the lib headers | ||
| dgilmore: but its compiled from a blank file | ||
| warren | dgilmore: 2K file? Come on. The extra load it creates on every yum transaction in dep resolution alone is not worth the effort. | |
| dgilmore: that is an incredibly weak argument if that's all you have. | ||
| This was seriously making a mountain out of a mole hill. | ||
| dgilmore | warren: every 2k adds up. we need to do much better to be able to create small spins | |
| jeremy | fwiw, I think that leaving libcurl.so.3 in the main curl package is entirely reasonable. we don't require that people split out every single library into a separate package. the fact that this is different sonames but for the exact same bits doesn't change things | |
| nirik | the only advantage to a compat file is that it makes it more clear to the end user that they are using an old/compat version of something. | |
| spot | fwiw, i don't really care at this point, i'll cede to FESCo. | |
| jwb | look damnit, issue #2 is where the controversy comes in. so having some form of technical solution that makes it more acceptable seems like a pretty damn good compromise | |
| jeremy | dgilmore: having an additional package is going to mean more than a 2k hit almost certainly | |
| dgilmore | jeremy: possibly. | |
| warren | jwb: except saving 2K of filesystem space to exclude it is the only benefit? | |
| drago01 | nirik: they are using the same thing with a different name | |
| jds2001 | dgilmore: and if you require it, then you're out *more* than 2k | |
| dgilmore | jeremy: what do we do when someone accidently does it to something big | |
| drago01 | nirik: so not really something old and unmaintained | |
| nirik | drago01: right. | |
| jeremy | dgilmore: what do we do when someone accidentally statically links things? you file bugs | |
| bpepple | ok, we've got a lot of important stuff on the agenda today, and we can't afford to waste a lot of time on this. So I see two proposals basically. | |
| 1. Leave it as how spot fixed it. | ||
| 2. Add a compat sub-package. | ||
| j-rod | 3. yank it entirely | |
| (was proposed on the mailing list) | ||
| jwb | that was my mistake | |
| dgilmore | j-rod: which is honestly what id prefer. | |
| jwb | i retract 3 | |
| warren | There are detriments to #2, while the only benefit is 2k less data if you don't want it. | |
| j-rod | which is why I figured #2 to be a happy compromise | |
| dgilmore | since the only user AFAIKT is adobe flash | |
| and i honestly dont think we should go out of our way to help them | ||
| warren | dgilmore: if your actual goal is to disallow proprietary software from our platform, then I'm happy to help implement that. let's start by ripping out the plugin finder from firefox. | |
| spot | i think we'll only be making our userbase suffer. | |
| drago01 | dgilmore: we don't want to help them but our users | |
| j-rod | honestly, I don't really care that much one direction or the other, I just wanna get to stuff that actually matters to me... :) | |
| mjg59 | dgilmore: We've already gone out of our way. Doing anything else at this point is arguably going out of our way to spite them. | |
| spot | adobe already doesn't care because, "it works on Ubuntu" | |
| jds2001 | spot: +1 | |
| dgilmore | warren: honestly how hard is it for adobe to release a version that links to the new soname? | |
| bpepple | Could I get a show of hands from FESCo member on which proposal they want? | |
| nirik | I vote for #1, with the proviso that those who want a compat package should get package guidelines for them approved. | |
| warren | dgilmore: it wont work on RHEL4 and RHEL5 in that case, and they are unwilling to QA two binaries. | |
| jwb | bpepple, i'm for proposal #2 | |
| * jds2001 for proposal 1 | ||
| dgilmore | warren: thats there problem not ours | |
| warren | dgilmore: This is exactly what I mean by extremism is not productive. | |
| j-rod | but it becomes our problem when users (like linus) bitch and moan about no working flash. :) | |
| * dgilmore gives up and lets us walk away from our goals | ||
| dgilmore | its the same thing as turning around and saying we will put an old X in so nvidia will work | |
| sadmac2 | our goals are to spread foss, not to be pointy-headed pains in the asses | |
| drago01 | dgilmore: our goal was never to _prevent_ people from running closed source stuff | |
| * nirik waits for other fesco votes... | ||
| warren | dgilmore: Yes, if the old X were the same ABI as the new X but with a different version number. | |
| jwb | nirik, you didn't vote | |
| nirik | I vote for #1, with the proviso that those who want a compat package should get package guidelines for them approved. | |
| Kick__ | I'm for proposal 1. This already took way too much of our time, no need to prolong this by having spot repack this | |
| bpepple | +1 to proposal #1, just so we can end this. | |
| jds2001 | dgilmore: i go to local beginner's workshops and stuff all the time. Telling people that Flash won't work in F10, and that I was part of the decision, just doesn't fly with me. That's why I vote for #1 | |
| * j-rod abstains from voting | ||
| jwb | jds2001, i realize this is a complete side issue, but what do you tell them about mp3 playing? | |
| drago01 | dgilmore: maintaing a compat X would have been a MAJOR pain ... while this one costs us nothing | |
| bpepple | ok, I see 3 votes for proposal #1, and 2 for proposal #2, and one abstaining vote. | |
| jwb | jds2001, answer that elsewhere. i'm just curious | |
| warren | Now if someone wants to entertain ripping out the plugin finder, I'm actually in support of that. Isn't that our last remaining pointer in the distro to proprietary software? | |
| jds2001 | jwb: it's patent encumberd :/ | |
| * dgilmore abstains | ||
| jwb | what? | |
| drago01 | jwb: mp3 | |
| bpepple | ok, we've got only a half-hour left, we have to end this discussion for today. | |
| jwb | sorry, dgilmore what? | |
| dgilmore | jds2001: so is flash, your arument doesnt fly | |
| j-rod | bpepple: I saw 4 for #1 -- jds2001, Kick_, nirik and bpepple | |
| jwb | dgilmore, i would really prefer it if you voted | |
| bpepple | j-rod: thanks, I missed Kick_'s vote. | |
| dgilmore | jwb: if i were forced to it would be #2 of the 2 | |
| jwb | thanks | |
| bpepple | ok, so it looks like we have 4 votes for #1, and 3 votes for #2. | |
| warren | does fesco need 5 votes to pass, or majority of whoever is in the meeting? | |
| * stickster notes that if this meeting goes over, he'll prevail on Docs to give right-of-way | ||
| drago01 | and one abstain | |
| so 8 people voted | ||
| jwb | dwmw2_gone didn't vote | |
| warren | notting? | |
| dgilmore | warren: notting is on vacation | |
| warren | who were the three for #2? | |
| bpepple | I think I counted j-rod in there, when he abstained. | |
| j-rod | fwiw, I have a slight personal preference for #2 over #1, if I were forced to not abstain... | |
| * nirik notes he has to leave in about 5min... | ||
| dgilmore | let move on and discuss this on the mailing list | |
| jwb | again? | |
| call it as #1 is the winning proposal | ||
| dgilmore | :( fair enough | |
| bpepple | jwb: agreed. | |
| moving on..... | ||
| warren | I'm sorry this has been a huge time sink. | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/30SecondStartup | ||
| warren | 30 seconds should be fast? =) | |
| sadmac2 | this proposal has always seemed a bit vague to me | |
| there's no actual changes suggested in it | ||
| * Kick__ wonders if this is still doable without upstarts parallel bootup. | ||
| drago01 | isn't this related to the upstart changes discussed today? | |
| sadmac2 | Patallel bootup's benefits come into question a lot | |
| mclasen | no, this is mostly about harald fixing readahead | |
| j-rod | agree w/sadmac2, its rather vague | |
| mclasen | but that got stuck between auditd and the kernel... | |
| nirik | yeah, more detail on specific things that will be done to improve time would be nice... | |
| sadmac2 | earlier ubuntu experiments seem to indicate there's more to reap than the worst-case had suggested, but its not enough data for a theory | |
| nirik | the test plan could use more specifics too... what to install, when to start timing (bios? power on?) | |
| Kick__ | anyway, the contingency plan covers that. Lets make the bootup as fast as possible, including the modprobe and readahead stuff | |
| mclasen | I'd table this until harald's readahead work gets unstuck, maybe ping him about that... | |
| Kick__ | nirik: 30sec bootchart time, most likely | |
| j-rod | back-burner it +1 | |
| bpepple | mclasen: sounds like a plan. we'll push it to next week's meeting. | |
| sadmac2 | Kick__: I'd heard talk of modifying bootchart to not stop timing until a firefox instance is successfully launched | |
| bpepple | moving on to the next feature...... | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/ApplianceTools | ||
| sadmac2 | so init-to-usable time | |
| jds2001 | sadmac2: yeah, thats mentioned on the page | |
| bpepple | This is similar to what rpath provides isn't it? | |
| jds2001 | yes. pretty similar | |
| Kick__ | didn't FESCo punt spins to rel-eng ? | |
| jwb | yes | |
| huffd | Not sure what yall want to hear about/discuss about appliance feature.... | |
| bpepple | Kick_: yes. | |
| dgilmore | +1 to ApplianceTools | |
| jds2001 | yeah, i questioned that oo | |
| bryan_kearney | this is tools + a spin | |
| jds2001 | this is more of a toolchain | |
| +1 here | ||
| bryan_kearney | the spin is for easy consumption | |
| huffd | SO the appliance feature is two things, appliance-tools package, and AOS spin | |
| nirik | +1 from me. | |
| bpepple | +1 to ApplianceTools. | |
| Kick__ | +1 | |
| * nirik has to go now... | ||
| bpepple | nirik: later. | |
| j-rod | +1 | |
| bpepple | ok, I see six "+1", so we've approved this feature. | |
| moving on..... | ||
| --- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/ApplicationInstaller | ||
| jwb | bryan_kearney, please be sure to send the spin part to rel-eng | |
| huffd | huff, ack | |
| bryan_kearney | jwb: will do | |
| jwb: working through the spins group now | ||
| jwb | k | |
| sadmac2 | what does this do to us security-wise? is there a new category of vulns that come out of this feature? | |
| dgilmore | i have issues with "Log in with Fedora Account System username and password" | |
| jwb | why? | |
| jds2001 | dgilmore: that's just for commenting | |
| dgilmore | we should not require people to have fas accounts to use this feature | |
| sadmac2 | that does limit usefulness to end users | |
| dgilmore | jds2001: doesnt matter | |
| * jds2001 tends to agree | ||
| rnorwood | dgilmore: FAS account isn't required for the main purpose of installing apps. | |
| jwb | so... | |
| jds2001 | maybe a captcha or something for spam | |
| drago01 | yeah users should be able to just use it (without any additional barrieres like accounts) | |
| jwb | how does the app verify that it's only installing on a Fedora system? | |
| rnorwood | dgilmore: FAS account is required to do things like post reviews, etc. | |
| dgilmore | rnorwood: plenty more people could provide feedback | |
| warren | rnorwood: one thought | |
| dgilmore | this feature could also be taken up by other distros | |
| rnorwood | dgilmore: true. My view is that it's more valuable if feedback is attributed to a person - and the plan is to expand that from 'FAS' to 'any openid' | |
| warren | rnorwood: have you seen lmacken's CAPTCHA for unauthenticated commenting in bodhi? | |
| dgilmore | with packagekit it should work everywhere | |
| bpepple | rnorwood: that seems reasonable. | |
| rnorwood | jwb: It doesn't, it requires a browser plugin that owen has written to do the install. | |
| dgilmore | rnorwood: id prefer the abbility to post feedback without having a user account. | |
| jwb | rnorwood, hm ok | |
| rnorwood | And my thinking for non-fedora users of this feature is to run a different instance of the webapp (probably sharing data) | |
| dgilmore | rnorwood: does it tie into packagekit? | |
| warren | rnorwood: have you seen the unauthenticated commenting in bodhi? | |
| rnorwood: might be useful here as well. | ||
| rnorwood | dgilmore: Yes. Owen's plugin calls packagekit's API | |
| rnorwood | warren: I don't have a religious aversion to unauthenticated comments | |
| bpepple | +1 to this feature. | |
| dgilmore | rnorwood: so its definatly possible that it could find its way into other distros. even using our frontend | |
| jwb | i'm just wondering if people are easily going to be able to use this with an OpenSuSE system (for example) and have distaster | |
| but that seems overly paranoid | ||
| rnorwood | dgilmore: well, for instance, one issue is that package names are not consistent across distros. | |
| dgilmore | rnorwood: sure | |
| jwb | +1 from me. seems neat | |
| mclasen | most of the feedback here should probably go on the discussion tab of the feature... | |
| rnorwood | jwb: no, because all it does is say 'install package by name' | |
| bpepple | mclasen: agreed. | |
| drago01 | dgilmore: well nothing prevents other distros to point to our repos | |
| j-rod | +1 here | |
| dgilmore | other than the fas requirement seems good to me | |
| Kick__ | +1 | |
| rnorwood | mclasen: agreed here too - or on mailing list | |
| jds2001 | +1 here | |
| bpepple | ok, I see five "+1", so we've approved this feature. | |
| anyone have anything else to add before moving on? | ||
| --- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/Eclipse34 | ||
| rnorwood | bpepple: just a quick note that the only things for this landing on the ISO will be owen's plugin and a desktop file to put it in the app menu | |
| bpepple | rnorwood: thanks for the clarification. | |
| jwb | the strikeout in this page is awesome | |
| j-rod | is an updated eclipse really feature-worthy? | |
| jwb | yes? | |
| jwb | for publicity reasons | |
| j-rod | I mean, I'm fine with publicizing updated packages, but do we really need to vote on them as new features? | |
| I don't see a feature page for shipping a 2.6.27 kernel anyway | ||
| dgilmore | it would be nice if there was some idea in the feature what new features upstream has added | |
| j-rod | (of course, I haven't actually looked...) | |
| sadmac2 | j-rod: eclipse is a huuuuuuge deal for a lot of people | |
| jwb | major upgrades should be tracked via Feature so rel-eng/qa can see the fallback options are in case things are broken | |
| j-rod | and eclipse isn't even installed on lots of systems | |
| jwb | j-rod, dude... the kernel just isn't that glamorous anymore ;) | |
| j-rod | heh | |
| bpepple | +1 to this feature. I pretty much agree w/ jwb & sadmac2. | |
| drago01 | j-rod: we always update kernels during the lifetime of a release so its not worth it | |
| jwb | +1 | |
| jds2001 | for sure this merits a release note since there's breakage | |
| j-rod | drago01: we always update lots of packages... | |
| oh, sorry, didn't read all of that | ||
| Kick__ | +1 from me | |
| jds2001 | +1 | |
| \ | ||
| dgilmore | +1 (with the caveat, what new features are in it to advertise) | |
| jds2001 | needs some work on the test plan, though.... | |
| j-rod | +1 | |
| bpepple | dgilmore: could you add that to the discussion page? | |
| dgilmore | it would be nice to say new eclipse with foo abd bar | |
| rather than new eclipse | ||
| bpepple | ok, I see five '+1', so we've approved this feature. | |
| j-rod | but I'm writing a feature page for upgrading dvgrab from 3.1 to 3.2. | |
| bpepple | j-rod: ;) | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/FirstAidKit | ||
| poelcat | j-rod: why are you so down on features? :) | |
| drago01 | j-rod: new features the kernel provides are in seperate pages (we had tickless, now webcam ...) | |
| j-rod | heh | |
| sadmac2 | j-rod: you're complaining that we call all new packages features? there are places where they call all their bugs features. | |
| j-rod | I'm not down on features, just the idea that we need to approve the eclipse people shipping the latest upstream release | |
| that's already what fedora is | ||
| its expected | ||
| we can tout that without having to rubber-stamp it | ||
| jwb | side issue | |
| dgilmore | bpepple: discussion started | |
| bpepple | dgilmore: thanks. | |
| j-rod | sorry. :) | |
| * j-rod shuts up now | ||
| bpepple | ok, the FirstAidKit looks pretty cool. | |
| sadmac2 | I like this a lot. I think the "oh crap, it broke" use case has been neglected, and with the ammount of dated/disinformational "make your graphics work" howtos on the internet, new users break fedora a lot. | |
| j-rod | now *this* is a new feature. :) | |
| +1 | ||
| jeremy | having it publicized a bit could also be a big win for getting more people contributing plugins (the things which actually help fix your system) | |
| bpepple | +1 here also. | |
| Kick__ | +1 for FirstAidKit, I like that feature and the plugin capabilities | |
| dgilmore | do we have any idea what plugins currently exist | |
| jds2001 | +1 | |
| dgilmore | is there an easy framework for writing new ones? | |
| i dont see either of them covered | ||
| jwb | +1 | |
| sadmac2 | dgilmore: https://fedorahosted.org/firstaidkit/ | |
| jeremy | dgilmore: root password, xorg reconfig, and something with mdadm are plugins that are written. framework for writing new ones exists, is documented, and is going to be the subject of one of the fudcon presentations | |
| sadmac2 | dgilmore: near the bottom of that page | |
| bpepple | ok, that's five '+1' to this feature. It's been approved. | |
| f13 | dgilmore: there was some good pages written up for creating plugins, we tried to get people doing plugins at FUDCon | |
| dgilmore | jeremy: ok we should be very clear of the limitations when we advertise this | |
| quaid | f | |
| dgilmore | we dont want people thinking it will do everything | |
| bpepple | stickster: you mind if we go 10 minutes late? I'd like to finish one or two more features. | |
| dgilmore | we its only a small and growing subset | |
| jds2001 | dgilmore: https://fedorahosted.org/firstaidkit/wiki/FirstaidkitPluginDoc | |
| zodbot | <http://tinyurl.com/5zaxmf> (at fedorahosted.org) | |
| quaid | bpepple: roll with it | |
| bpepple | ok, moving on then..... | |
| https://fedoraproject.org/wiki/Features/GNOME2_24 | ||
| quaid | Docs :: we'll start in #fedora-docs, then move here | |
| jwb | +1 | |
| dgilmore | +1 ill add to the discussion page that we should clearly state what is covered and here is where you can add coverage | |
| Kick__ | gnome2.24 is only 40% done ? Is there enough time to get this ready for inclusion ? | |
| bpepple | +1 though I have some comments to add about telepathy on the discussion page. | |
| quaid: thanks. | ||
| stickster | bpepple: go right ahead | |
| stickster | Ah, I'm late as usual. | |
| mclasen | Kick__: gnome 2.24 is already 73% done... | |
| Kick__ | ok, the page needs an update then | |
| mclasen | yeah | |
| Kick__ | +1 in that case | |
| bpepple | jds2001, j-rod: you have an opinion on this feature? | |
| j-rod | +1 | |
| jds2001 | +1 here. A complete GNOME test plan would be great, though, as well as mention of what the "notable new features" are :) | |
| sadmac2 | jds2001: I'd imagine a couple of links to fd.o could take care of most of that | |
| bpepple | ok, that's six '+1' to this feature, so we've approved it. | |
| j-rod | although again, I already assume every fedora release is going to be carrying the latest gnome release | |
| mclasen | jds2001: a "complete gnome test plan" is a pretty ambitious undertaking... | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Features -- http://fedoraproject.org/wiki/Features/PythonNSS | ||
| jds2001 | mclasen: i know :) | |
| bpepple | This is one we voted against last week, but the owner gave us additional info about it being written inhouse. | |
| jds2001 | that's why it's a nice-to-have.. | |
| dgilmore | the python openssl bindings are really bad | |
| j-rod | +1 for python-nss this round... | |
| bpepple | +1 here also. | |
| jds2001 | imo, it then becomes something that differentiates Fedora, so +1 here | |
| dgilmore | +! | |
| Kick__ | no idea on that one | |
| bpepple | jwb: you have an opinion? | |
| jwb | sorry, reading | |
| bpepple | jwb: np. | |
| jwb | +1 | |
| bpepple | alright, that gives us five '+1', so this feature has been approved this round. | |
| jds2001 | does warrant release notes, though. | |
| jwb | yes | |
| bpepple | ok, let's do one more feature, and then wrap it up for this week. | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/Sugar | ||
| j-rod | would also like to see some notes on plans to convert existing stuff to use python-nss | |
| probably an f11 feature though | ||
| bpepple | j-rod: yeah, that not a bad idea. I'll add something to the discussion page. | |
| sadmac2 | how would sugar's presence look in fedora? would it be an option alongside gnome/kde/xfce in anaconda? | |
| jds2001 | you're throwing me off bpepple :) | |
| sadmac2 | also 5% ?! | |
| * jds2001 had FF tabs open in the right order :) | ||
| gregdek | sadmac2: Probably more like 50%, really. An awful lot of sugar is already packaged. | |
| rnorwood | sadmac2: Yes, as another option in GDM, if you have it installed | |
| sadmac2 | cool | |
| rnorwood | sadmac2: apologies for the low % complete - gregdek's fault. | |
| sadmac2 | heh | |
| bpepple | jds2001: yeah, I tried to grab a couple of features I thought wouldn't have prolonged discussions since we're short on time. | |
| gregdek | rnorwood: Bite my shiny metal ass. | |
| bpepple | +1 to Sugar. | |
| j-rod | +1 | |
| Kick__ | +1 | |
| jds2001 | +1 | |
| jwb | +1 only if it comes with the background set to a picture of gregdek's shiny metal ass | |
| dgilmore | +1 | |
| * jeremy refuses to add pictures of gregdek's shiny metal ass to the distro | ||
| jeremy | :) | |
| bpepple | ok, that's six '+1', so we've approved Sugar as a feature. | |
| rnorwood | jeremy: it would be a win over ubuntu. | |
| * gregdek is buffing. | ||
| dgilmore | jeremy: i have upshort pictures of kernel hackers can we add those? | |
| gregdek | lolol | |
| sadmac2 | rnorwood: yes, but at what cost? | |
| gregdek | No. | |
| bpepple | ok, we've used enough of the doc groups time, so let's end this meeting. | |
| * 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!