From Fedora Project Wiki
Topic changed on #fedora-townhall by spevack!n=spevack@fedora/mspevack: Ask your questions in #fedora-townhall-public | 09:00 | |
dwmw2 (i=ctrlprox@baythorne.infradead.org) joined #fedora-townhall. | 09:00 | |
#fedora-townhall: mode change '+v dwmw2' by ChanServ!ChanServ@services. | 09:00 | |
knurd (n=thl@fedora/thl) joined #fedora-townhall. | 09:00 | |
spevack | ok candidates, i hope your typing fingers are warmed up. | 09:00 |
---|---|---|
spevack | we'll start shortly | 09:00 |
spevack | May I get a roll call? | 09:00 |
cwickert | Christoph Wickert | 09:00 |
mdomsch (n=mdomsch@cpe-70-124-62-55.austin.res.rr.com) joined #fedora-townhall. | 09:00 | |
mpdehaan (n=mpdehaan@cpe-075-182-078-253.nc.res.rr.com) left irc: Client Quit | 09:00 | |
#fedora-townhall: mode change '+v mdomsch' by ChanServ!ChanServ@services. | 09:00 | |
Action: skvidal is here | 09:00 | |
Action: dwmw2 | 09:00 | |
Kevin_Kofler | Present. | 09:00 |
notting | Bill Nottingham is here | 09:00 |
mpdehaan (n=mpdehaan@cpe-075-182-078-253.nc.res.rr.com) joined #fedora-townhall. | 09:00 | |
maxamillion | Adam Miller is here | 09:01 |
spam10707 (n=spam1070@ool-44c667d7.dyn.optonline.net) joined #fedora-townhall. | 09:01 | |
stickster (n=paul@fedora/stickster) joined #fedora-townhall. | 09:01 | |
#fedora-townhall: mode change '+o stickster' by ChanServ!ChanServ@services. | 09:01 | |
harish (n=harish@nat/redhat/x-96d82a01f8da913e) joined #fedora-townhall. | 09:01 | |
ixs | <-- present | 09:01 |
spevack | Ok, while we wait another minute or two for any stragglers | 09:01 |
spevack | As your moderator for this hour, i'll make a few initial comments | 09:01 |
spevack | This Townhall meeting is for candidates for the Fedora Engineering Steering Committee. | 09:02 |
mclasen (n=mclasen@nat/redhat/x-be6396c0c0bf95ed) joined #fedora-townhall. | 09:02 | |
spevack | We're going to be fielding any/all questions from #fedora-townhall-public and i'll be posting them in here for people to answer. | 09:02 |
spevack | I'd encourage everyone in the audience to refer to these wiki pages: | 09:02 |
spevack | Elections | 09:02 |
spevack | Elections/Questionnaire | 09:02 |
jwb (n=jwboyer@fedora/jwb) joined #fedora-townhall. | 09:02 | |
#fedora-townhall: mode change '+v jwb' by ChanServ!ChanServ@services. | 09:02 | |
spevack | (your questions need not be limited to those on the list) | 09:03 |
abadger1999 (n=abadger1@65.78.187.8) joined #fedora-townhall. | 09:03 | |
spevack | Development/SteeringCommittee/Nominations | 09:03 |
spevack | The schedule for all the townhall meetings is here: | 09:03 |
spevack | Elections#IRC_Town_Halls | 09:03 |
Kevin_Kofler | Unfortunately, it looks like knurd hasn't posted our answers to the election questionnaire as he had planned. | 09:03 |
spevack | Any comments from the candidates before we get started? | 09:03 |
cwickert | Kevin_Kofler: he wanted to do this after work today | 09:04 |
Action: stickster notes that knurd is working on that right now, according to #fedora-townhall-public | 09:04 | |
spevack | knurd is working on getting the answers from the Candidate Questionnaire online | 09:05 |
spevack | ok, we've got our first question for the candidates, from inode0. | 09:05 |
spevack | Last term FESCo decided to not accept OVM until additional | 09:05 |
spevack | conditions were met | 09:06 |
spevack | Did FESCo make the right decision? | 09:06 |
spevack | - | 09:06 |
Action: skvidal thinks rehashing past decisions is a bad idea | 09:06 | |
spevack | and first off | 09:06 |
spevack | What is OVM, for the audience? | 09:06 |
maxamillion | Open Verification Methodology : IEEE 1800 SystemVerilog standard | 09:06 |
spevack | since folks are asking | 09:06 |
ixs | I think, OVM were design files for integrated chips | 09:06 |
Kevin_Kofler | It's some SystemVerilog code. | 09:07 |
skvidal | rehashing old decisions is not going to do anything other than attempt to pass blame around | 09:07 |
skvidal | that's not helpful and it's not progress | 09:07 |
Kevin_Kofler | Basically a "program" for a SystemVerilog simulator. | 09:07 |
spevack | inode0 states that he doesn't want to re-hash, but he'd like to know who agreed with the decision, and who disagrees with it -- presumably because he'd like to get some insight into how people think on this issue, and where those differences of opinion are. | 09:07 |
skvidal | The program does not do anything w/o the non-free content, aiui | 09:07 |
Kevin_Kofler | The problem is that we didn't have any support for actually simulating that SystemVerilog. | 09:07 |
notting | It's content used to verify electronic designs - as I understand it, the content is freely licensed, but (currently) all programs that use the cotent are not | 09:07 |
Kevin_Kofler | So you couldn't do anything with that content. | 09:07 |
skvidal | ah, then I was explaining it backward | 09:08 |
skvidal | sorry | 09:08 |
Kevin_Kofler | Thus I think that yes, FESCo made the right decision to block it. But it seems SystemVerilog support is coming to Free Verilog simulators, so the whole point might become moot soon. | 09:08 |
maxamillion | I think that if it doesn't violate any of the guidelines it should have been included. | 09:09 |
notting | i think it was the right decision per the guidelines, although it's a bit of a gray area | 09:10 |
notting | (it's the inverse of some of the games, where we have an open source game engine, and content of varying licenses) | 09:10 |
ixs | Right, the code versus content debate. OVMs were deemed content and as such are not packagable for Fedora. If that understanding of OVM was false, I'd suggest the interested party should have FESCO revisit the issue and try to persuade them by explaining why it's not content and shippable. | 09:10 |
maxamillion | notting: exactly, and those games are in the repositories | 09:10 |
Kevin_Kofler | The infamous autodownloader... | 09:11 |
Kevin_Kofler | Yet another big can of worms. | 09:11 |
Action: cwickert has to admit that he did not follow this discussion that closely, but he knows that Chitlesh and others put great work into FEL, EDA and OVM, nevertheless he thinks that the decision from FESCO was right at that time | 09:11 | |
notting | maxamillion: because of the different rules for code and content. OVM is 'content', more or less | 09:11 |
spevack | Any other comments on this topic? If not, we'll move on in about 1 minute | 09:12 |
spevack | ok, next question coming | 09:12 |
spevack | Evolution asks, "which is more important to the candidates? default security (protecting users from themselves) or ease of use for newer linux converts?" | 09:12 |
skvidal | Evolution: not having false dichotomies is most important to me | 09:13 |
jwb (n=jwboyer@fedora/jwb) left irc: Remote closed the connection | 09:13 | |
notting | that doesn't sound like an either/or choice - in fact, those may agree more often than not | 09:13 |
jwb (n=jwboyer@24-247-191-219.dhcp.aldl.mi.charter.com) joined #fedora-townhall. | 09:13 | |
maxamillion | I think that's a loaded question and there should be a middle ground where ease of use and security can be equal considerations | 09:13 |
skvidal | it's not a choice of guns or butter | 09:13 |
ixs | Isn't protecting them from themselves often considered the same then making it easier for the typical use case? | 09:13 |
Kevin_Kofler | I don't think the system should keep the user from doing what they want. | 09:13 |
#fedora-townhall: mode change '+v jwb' by ChanServ!ChanServ@services. | 09:13 | |
Kevin_Kofler | That said, "security" and "protecting users from themselves" is not quite the same thing. | 09:14 |
ixs | but personally, I do not want the system be dumbed down. If the user wants to shoot himself in the foot, I'll happily hand him the gun and even through in some rope to hang himself afterwards. Fixing up broken systems can be a very valuable learning experience in itself. | 09:15 |
Kevin_Kofler | Though in some cases it can be (if you ban the user from doing something stupid, it might also prevent a trojan doing that stupid thing). | 09:15 |
ixs | "throw in some rope" even | 09:15 |
cwickert | Evolution: I think users need to be free to do what they want but they also need to be secure. making certain devices world writable by default as Ubuntu does just to gett less bug reports is not a solution | 09:15 |
Kevin_Kofler | ixs: +1 | 09:15 |
maxamillion | I do however think that security is key and that (like with the SELinux Troubleshooter) there should always be a mechanism to help the user in the event that a security component *might* cause a speed bump in user experience | 09:15 |
Kevin_Kofler | Dumbing down the system by removing useful features just because they can be abused doesn't solve anything. | 09:16 |
lmacken (n=lmacken@fedora/lmacken) joined #fedora-townhall. | 09:16 | |
notting | security should be a priority - shipping things set up insecurely helps no one. if there are issues with how things are configured securely, we should fix the issues the right way (separate implementers from UI, as in policykit) rather than do the quick hack (run GUI apps as root, as in consolehelper) | 09:16 |
ixs | maxamillion: security is key, especially on internet connected systems. But if the user is running his device on a secure network, he should be free to enable rsh and offer his rootfs via nfs to *(rw). And right now, we're coming with sane defaults (e.g. selinux enabled) and can disable these with one command. That's how I'd like to see Fedora continue. | 09:17 |
Kevin_Kofler | Well, I think that if the security mechanism causes speed bumps in the user experience, the security mechanism is broken. | 09:17 |
geppetto (n=james@code.and.org) joined #fedora-townhall. | 09:17 | |
Kevin_Kofler | A popup saying "Sorry, I just kept you from doing your work." is not helpful. | 09:17 |
maxamillion | ixs: I completely agree, didn't mean to imply that I wanted it to go a separate direction | 09:17 |
skvidal | spevack: just out of curiosity - are we going to have a lot of questions which are horribly loaded and pointed? | 09:18 |
skvidal | spevack: is the point of the townhall to play gotcha with the candidates? | 09:18 |
spevack | skvidal: i think the next question has some good room for discussion | 09:18 |
ixs | Kevin_Kofler: the problem in my opinion is: security is not a toggle, it's a process. So there have been speedbumps and we might have handled the SELinux introduction a bit better with better documentation around the FC4-6 timeframe. But I'm very glad that we do offer SELinux and have it enabled by default because it can only get better by having the public interact with it. | 09:18 |
spevack | Would anyone like more time with this question? | 09:19 |
skvidal | spevack: does it ask "when did you stop beating your wife?" b/c that's what I'm expecting :) | 09:19 |
ixs | god no, carry on. :ED | 09:19 |
Kevin_Kofler | notting: But for that to work in KDE, we need to have a working policykit-qt, without PolicyKit changing API under us. | 09:19 |
Kevin_Kofler | Otherwise we're stuck with kdesu. | 09:19 |
notting | i'd agree that setroubleshoot isn't always the most helpful - it's the sort of thing that almost is better to directly inform the developers rather than the users | 09:19 |
spevack | ok, there's been some discussion in -public around this question, so it's going to take me a few pastes to get it all in. | 09:19 |
spevack | --- | 09:19 |
spevack | abadger1999 asks, "Where do you stand on letting controversial packages into the Everything repo? Should filtering be done before packages even hit the repo or should they be done at a higher level?" | 09:19 |
spevack | abadger1999 adds, "Another way to put it would be is the Fedora Package Collection the "Universe of all open source" (as tiemann phrased it in an early strawman)?" | 09:20 |
spevack | 09:20 | |
spevack | then | 09:20 |
spevack | 09:20 | |
spevack | cwickert asked abadger1999 to define "controversial packages" to which abadger1999 replied, "I'm not sure I should except by example from current events -- packages that incude flags, packages whose sole purpose is to retrieve pornography from the internet, packages which can retrieve pornography from the internet (like webcollage)" | 09:20 |
spevack | 09:20 | |
Last message repeated 1 time(s). | 09:20 | |
spevack | and | 09:20 |
spevack | inode0 adds, "put another way, I could be asking how much scrutiny we want to place on content when we place little on code. How important is the code vs. content distinction and why is it important?" | 09:20 |
spevack | Go! :) | 09:20 |
spevack | --- | 09:20 |
Action: spevack waits while everyone reads | 09:21 | |
skvidal | part 1: I think there should be no conflicts in pkgs in fedora, period, ever. If that means the pkgers have to use alternatives ( bleah) then so be it | 09:21 |
dwmw2 | I'd love to be able to include everything, to be honest. | 09:21 |
dwmw2 | pragmatism interferes with that desire a little | 09:21 |
Kevin_Kofler | There's an assumption in the question, which is that we want to filter this content at all. | 09:21 |
Kevin_Kofler | I don't think I agree with that premise, at least for the quoted examples. | 09:21 |
ixs | abadger1999: Our process for deciding what goes into the everything repo should _only_ be based on the technical details of the packaging guidelines. Exception for patents or other legally problematic packages apply as well. Any further restrictions should not be imposed. If it finds a reviever and passes, it goes in. As simple as that. I might not like it personally and never install it, but who am I to judge what other ... | 09:21 |
skvidal | part 2: what the code does it less important provided it is legal to distribute at all | 09:21 |
dwmw2 | I bundle patented stuff with those same examples | 09:21 |
ixs | ... people do on their computers. | 09:22 |
twanj (n=chatzill@c-174-48-8-60.hsd1.fl.comcast.net) joined #fedora-townhall. | 09:22 | |
skvidal | part 3: I don't want to have fedora doing content-only bundles of non-freesoftware-related stuff | 09:22 |
maxamillion | I think FESCo should allow packages based on technical merit and their compliance with the guidelines, beyond that I don't see why FESCo would be governing what users can and can have access to via the repositories | 09:22 |
cwickert | for gnaughty I think we should not include this package. not because it's a downloaded for adult content, but because there's an URL hardcoded in the source. we have no control over the site we are linking to. for flags it's completely different. I don't think we should remove them for political reasons | 09:22 |
dwmw2 | don't we ship a bunch of stuff with URLs hardcoded? | 09:22 |
dwmw2 | and isn't that trivial to 'fix' anyway? | 09:23 |
cwickert | dwmw2: for example? | 09:23 |
dwmw2 | I'm pretty sure gmpc has hard-coded urls for downloading album art | 09:23 |
skvidal | dear world | 09:23 |
maxamillion | dwmw2: i think we ship stuff with URLs in config files, but this application actually has it compiled in the C source | 09:23 |
dwmw2 | I sure as hell never told it | 09:23 |
skvidal | let's not discuss gnaughty again | 09:23 |
Kevin_Kofler | Re flags: I strongly oppose any restrictions on country flags, showing flags is just free speech. | 09:23 |
dwmw2 | skvidal: +1 :) | 09:23 |
notting | to take the gnaughty example, i think it's a stupid program - it's badly written, it hardcodes a particular site, essentially functioning as advertising. i don't think it of any particular benefit for Fedora to ship it, and it's likely to cause more harm in the community than any good it could possibly do. i don't think we should include it. however, i think that should be a *conscious* choice from the packagers ('i'm not shipping this because | 09:23 |
notting | it's dumb') not a guideline-related choice | 09:23 |
skvidal | dear rest of world | 09:23 |
skvidal | let's not discuss flags again | 09:23 |
skvidal | kthxbai | 09:23 |
dwmw2 | Kevin_Kofler: My MP3 decoder is free speech too. | 09:24 |
Kevin_Kofler | Re pornography: I don't think we should censor that either. | 09:24 |
Kevin_Kofler | Well, shipping pure pr0n content in Fedora makes no sense, we're not in a business of shipping content. | 09:24 |
Action: skvidal watches the discussion devolve | 09:24 | |
dwmw2 | I think the reason not to ship content is different -- I think that's just not what Fedora is _for_. | 09:24 |
skvidal | wake me when this is important to more than 0.02% of our packages | 09:24 |
skvidal | great | 09:24 |
Kevin_Kofler | But shipping software like gnaughty, what's the problem? The implementation of gnaughty leaves much to be desired (hardcoded for one specific site etc.). | 09:24 |
dwmw2 | I think there are better places to aggregate and distributure 'content' | 09:24 |
spevack | notting: so if the packager decides, "I want to package it even though others think it's dumb" and it passes review, it goes in? | 09:24 |
cwickert | dwmw2: very different argument, because album art is only a couple of jpegs while the content from gnaughty is all kinds of stuff and I don't think the program does some filtering on mime types | 09:25 |
red_alert (n=red@id-als-docking-167.ethz.ch) joined #fedora-townhall. | 09:25 | |
Kevin_Kofler | But there are other packages like that which we happily accept. | 09:25 |
Kevin_Kofler | E.g. clients for Twitter and only Twitter. | 09:25 |
maxamillion | I don't think the pronographic downloading nature (or otherwise) aspect of a package should be grounds for its exclusion, but I do agree with the idea that we need to visit on the hard coding URLs topic | 09:25 |
dwmw2 | spevack: I don't see why not. Unless it's actively harmful to Fedora, why does it matter? | 09:25 |
Kevin_Kofler | So why is gnaughty different, just because of the nature of the site? | 09:25 |
maxamillion | Kevin_Kofler: I think that's different because twitter is a service with an API | 09:25 |
spevack | dwmw2: fair enough. i'm just asking the followups that occur to me :) | 09:25 |
maxamillion | where as gnauthy is just sweeping a site and stripping download links out | 09:26 |
maxamillion | gnaughty* | 09:26 |
notting | spevack: probably... i just wish they would think more about the overall project and goals, and less about "WOO PORN!" (which seemed to be the tone of some of the contents) | 09:26 |
spevack | heh | 09:26 |
skvidal | okay | 09:26 |
skvidal | so | 09:26 |
skvidal | can we move along? | 09:26 |
notting | then again... is this really a FESCo issue? isn't this more of a board issue? | 09:27 |
dwmw2 | probably, yes. | 09:27 |
skvidal | notting: and it's HARDLY A BOARD ISSUE | 09:27 |
spevack | abadger1999 notes that he's not interested in the specifics of gnaughty or flags, but rather the fundamental question of "do we want anything open source and legal in the Everything repo?" | 09:27 |
Action: spevack goes to start looking for the next question | 09:27 | |
Kevin_Kofler | skvidal: If it's not a FESCo issue nor a Board issue, whose issue is it? | 09:27 |
skvidal | exactly | 09:27 |
dwmw2 | abadger1999: yes, I think that we do, within reason. Unless it's a steaming pile of crap :) | 09:27 |
Kevin_Kofler | Somebody needs to make a decision. | 09:27 |
skvidal | +1 to keeping the steaming piles of crap out | 09:27 |
dwmw2 | shipping crap software hurts Fedora. To a certain extent, at leas.t | 09:27 |
Kevin_Kofler | We can't dismiss the discussion just because it's controversial. | 09:28 |
skvidal | Kevin_Kofler: we can from this townhall | 09:28 |
skvidal | Kevin_Kofler: since this is just for show | 09:28 |
skvidal | or better yet | 09:28 |
notting | from "Objectives" - "# Fedora is not a dumping ground for unmaintained or poorly designed software." that culls the list of everything-that-is-open-source | 09:28 |
maxamillion | abadger1999: I think we do, because if a packager is going to take the time to package and maintain it then they either find it useful or know someone who does and if it is useful and is compliant with the guidelines then i'm all for it | 09:28 |
skvidal | let's comment like we're supreme court nominees: I will not comment on a current case in controversy | 09:28 |
skvidal | how's that? | 09:28 |
ixs | notting: I think abadger1999 was asking "everything open source" following the assumption that there's a maintainer for it. If the crappy software actually works and has a responsible maintainer as well as passes review? Sure, it can go into Everything. We don't have to put it into the default spin however. | 09:29 |
spot (i=spot@redhat/spot) joined #fedora-townhall. | 09:30 | |
#fedora-townhall: mode change '+v spot' by ChanServ!ChanServ@services. | 09:30 | |
Kevin_Kofler | notting: Is that even true anymore since the Core-Extras Merge? Do our Objectives need fixing? | 09:30 |
Action: spevack will post the next question at :30 (90 seconds) | 09:30 | |
marcela (n=marca@62.40.79.66) joined #fedora-townhall. | 09:30 | |
maxamillion | ixs: +1 | 09:30 |
notting | Kevin_Kofler: i don't think we're properly serving our users if we hand them a bunch of crap that doesn't have active development | 09:30 |
Kevin_Kofler | Sometimes that "crap" is the only software to solve a real-world problem. | 09:31 |
Kevin_Kofler | At least the only Free one. | 09:31 |
skvidal | Kevin_Kofler: apparently it is a 'real world' problem that is only ever encountered by a small number of people | 09:32 |
skvidal | otherwise the crap wouldn';t be unmaintained | 09:32 |
maxamillion | and what person A thinks is crap, person B might think is the perfect solution | 09:32 |
skvidal | maxamillion: yes - person B is almost always wrong | 09:32 |
Action: spevack readies the next question | 09:32 | |
ixs | notting: there's a bunch of tools which have not seen updates for ~4 years. I think we'd be doing our users a disservice by culling them from fedora based on the "no active development". | 09:32 |
Kevin_Kofler | Once again, a violent +1 to ixs. | 09:32 |
maxamillion | skvidal: emacs vs. vim .... who's right and who's wrong? | 09:32 |
spevack | Here's a 2-paste question from muep, which almost makes me wish I was a candidate, so that I could answer it. | 09:33 |
skvidal | maxamillion: what the hell diference does that make? | 09:33 |
ixs | notting: ohh, forgot: these tools have usually not seen any development because they work. | 09:33 |
spevack | muep writes: | 09:33 |
skvidal | maxamillion: they are BOTH maintained | 09:33 |
spevack | do you guys want more time with this one? | 09:33 |
sharkcz (n=dan@plz1-v-4-17.static.adsl.vol.cz) joined #fedora-townhall. | 09:33 | |
spevack | or should we move on? | 09:33 |
skvidal | spevack: move on | 09:33 |
skvidal | please | 09:33 |
skvidal | for the love of space | 09:33 |
cwickert | move on | 09:33 |
spevack | ok, here we go -- 2 parts -- | 09:33 |
spevack | "The way Fedora pushes enhancement and feature updates to its stable update repositories is one of the things that makes Fedora interesting for many people, but at the same time, it makes Fedora a lot less suitable for new users, who may get confused when a updated program behaves differently today than yesterday. There have been pushes to both more bleeding edge and towards more stability." | 09:33 |
maxamillion | skvidal: when did anyone mention lack of maintenance? | 09:33 |
notting_ (n=notting@redhat/notting) joined #fedora-townhall. | 09:33 | |
#fedora-townhall: mode change '+v notting_' by ChanServ!ChanServ@services. | 09:33 | |
maxamillion | nvm | 09:33 |
spevack | "Should Fedora continue updating its stable package sets, or prioritize stability over new features, considering that there are many distros which already offer the 'no new features to stable' option?" | 09:33 |
spevack | EOF | 09:33 |
notting_ | woo, netsplit. | 09:34 |
dwmw2 | I think pushing updates is good -- but it's definitely best if we can avoid updates which dramatically change user interaction. | 09:34 |
Kevin_Kofler | Continue updating of course. | 09:34 |
skvidal | notting_: oddly, the question was asked directly to you and it was "when did you stop beating your kids?" | 09:34 |
maxamillion | I think we should continue on the way we do now | 09:34 |
notting_ | i think there's a middle ground - *no* new features to stable isn't appropriate. but *all* new features to stable isn't appropriate either | 09:34 |
Kevin_Kofler | As already said in the question, there are plenty of other options for those who don't want them. | 09:34 |
dwmw2 | when new stuff starts working, that's good. When old stuff _stops_ working as it used to | 09:34 |
dwmw2 | that's abd | 09:34 |
Kevin_Kofler | More consistency could be useful. I see some packages not getting even 100% compatible bugfix point releases pushed, those need to get updated more actively. | 09:35 |
dwmw2 | definitely. | 09:35 |
Kevin_Kofler | I think the kernel and KDE are examples for how to handle updates. | 09:36 |
notting_ | we shouldn't break things in released distros, as much as possible. someone who wants to keep some software working in Fedora shouldn't have to rebuild for stable every couple of months because an ABI changed out from under him | 09:36 |
ixs | muep: One of our principles is fast development, we're not putting that much importance on sta(bl)e APIs. So updates changing UI or similar do come with the territory and cannot really be prevented. These users might be better served with CentOS or similar Distros. On the other hand, I have observed that most of the breakage/rapid updates of functionality and UI do happen in rawhide and the releases are not seeing as much ... | 09:36 |
ixs | ... breakage as in the past. | 09:36 |
Kevin_Kofler | (Of course, I'm biased as for KDE. ;-) But the kernel folks are also getting it right.) | 09:36 |
cwickert | IMO the our latest release and latest release -1 should get enhancements, but release -2 should only get really important bugfixes and security updates. If you don't want any updates that are not absolutely necessary, install yum-security | 09:36 |
maxamillion | ixs: again ... +1 | 09:36 |
ixs | dwmw2: but +1 on the regressions. These should srsly stop. | 09:36 |
notting_ | and we shouldn't be doing things that break the documentation the docs group does, for example | 09:37 |
skvidal | okay, so maybe I'm confused | 09:37 |
Kevin_Kofler | And no, upgrading e.g. Amarok 1 to Amarok 2 in a stable release would not be a good idea. | 09:37 |
skvidal | but what in f10, for example, has broken badly inside the release cycle? | 09:37 |
Kevin_Kofler | We don't want a radically different UI with feature regressions as an update. | 09:37 |
skvidal | I've seen a number of things break in rawhide/betas | 09:37 |
Kevin_Kofler | But we do want improvements. | 09:37 |
cwickert | skvidal: dbus? | 09:37 |
skvidal | but those are supposed to break | 09:37 |
skvidal | cwickert: inside f10? when? | 09:37 |
Kevin_Kofler | Incremental ones like KDE 4.0->4.1->4.2. | 09:37 |
brunowolff (n=brunowol@65-117-131-164.dia.static.qwest.net) joined #fedora-townhall. | 09:37 | |
skvidal | cwickert: and wasn't it a bug - not a 'feature upgrade'? | 09:38 |
cwickert | skvidal: dbus broke packagekit, or was this already in F10? | 09:38 |
dwmw2 | ixs: it's not just stuff that people would call 'regressions', necessarily. If stuff that normal users use has moved and is different to how it was before, that sucks. | 09:38 |
cwickert | s/F10/F9 | 09:38 |
Kevin_Kofler | cwickert: That was an overzealous security fix, not an intentional major change. | 09:38 |
skvidal | cwickert: right - I thought that wasn't b/c something got rebased - I thought it was just due to a packaging bug with the default policy file | 09:38 |
stickster | That was a bad push of a package which was intended to fix an actual bug | 09:38 |
skvidal | cwickert: which could happen on ANY update - not just a rebase | 09:38 |
maxamillion | which happens | 09:38 |
cwickert | Kevin_Kofler: agreed | 09:38 |
notting_ | dbus was a execution issue, not a policy issue, imo | 09:38 |
skvidal | right | 09:39 |
ixs | dwmw2: ahh okay. thanks for clearing that up. | 09:39 |
skvidal | so by saying "no rebasing" for example | 09:39 |
skvidal | we would NOT solve the dbus issue | 09:39 |
skvidal | so can someone tell me a single issue which we would solve | 09:39 |
skvidal | by saying 'no rebases' | 09:39 |
skvidal | or 'slow the hell down'? | 09:39 |
skvidal | b/c I cannot name one outside of stuff in rawhide | 09:39 |
maxamillion | The fact is that in order to move forward at a rapid pace, there will always be a level of possibility that issues will happen, and this happens with all distros (even the Enterprise ones) | 09:39 |
skvidal | and we're NOT going to do this for rawhide ;) | 09:39 |
dwmw2 | you can't make a blanket policy for it. The 'risk' of updating varies wildly from package to package. | 09:40 |
notting_ | it would be nice to be able to get updates pushed faster, and the biggest issue there is the sheer amount of data. that's sort of orthogonal to policy | 09:40 |
dwmw2 | I think we do well enough at the moment | 09:40 |
cwickert | skvidal: I was asked to upgrade Xfce from 4.4 to 4.6 during F10 lifetime. | 09:40 |
skvidal | yep | 09:40 |
Kevin_Kofler | As for changing ABIs: while of course core stuff linked by "the world" like OpenSSL or OpenLDAP needs a constant ABI, I don't agree that this should be the case for libraries closer to the leaves. | 09:40 |
dwmw2 | I run my servers on Fedora, quite happily. | 09:40 |
skvidal | cwickert: yes, and? | 09:40 |
Kevin_Kofler | It's often unavoidable to bump the ABI for some libraries. | 09:40 |
skvidal | cwickert: I was asked for magical ponies and rainbows in yum | 09:40 |
skvidal | cwickert: people ask for stupid crap | 09:40 |
Kevin_Kofler | For example, the media player interface libraries often bump ABI when they add support for new hardware. | 09:40 |
Kevin_Kofler | We really want the new versions there! | 09:40 |
ixs | skvidal: right. And we shouldn't forget that users are filing bugzilla requests for a rebase in stable as well, as they want new features. Finding a middle ground is probably a good idea but I'd leave that up to disgression of the individual packager. | 09:41 |
notting_ | but when i see packages built simultaneously for f10/f11/f12 with a changelog of simply "upgrade to newer git/svn snapshot"... i don't think that's necessarily the right thing to be doing | 09:41 |
cwickert | skvidal: i refused, because the transition would have caused a lot of bugs as the Xfce test day showed | 09:41 |
Kevin_Kofler | Also because media player software like Amarok starts requiring the new version (but also because of the new hardware support). | 09:41 |
skvidal | cwickert: right so then the system worked | 09:41 |
Kevin_Kofler | Another example is libplasma in KDE 4.0->4.1->4.2, it bumped ABI whereas the core kdelibs didn't. | 09:41 |
cwickert | skvidal: exactly | 09:41 |
skvidal | cwickert: you, as the maintainer, are not stupid | 09:41 |
skvidal | cwickert: so we don't need to make a new policy | 09:41 |
skvidal | yay the system works | 09:41 |
Kevin_Kofler | Should we have stayed with KDE 4.0 on F9 just to avoid bumping the libplasma ABI? | 09:41 |
mmcgrath (n=mmcgrath@mmcgrath.net) joined #fedora-townhall. | 09:41 | |
spevack | How does any of Jesse's "call to action" for Fedora_Activity_Day_Fedora_Development_Cycle_2009#Background fit into this conversation? | 09:41 |
stransky (n=stransky@r11lj173.net.upc.cz) joined #fedora-townhall. | 09:41 | |
notting_ | Kevin_Kofler: no. it's a sliding scale based on the number of users of the lib, most likely | 09:42 |
Kevin_Kofler | (To me, the answer is an obvious "no", staying with 4.0 would have been silly.) | 09:42 |
Action: spevack starts makin gup his own follow-ups :) | 09:42 | |
skvidal | spevack: imo - it doesn't | 09:42 |
jwb | spevack, it doesnt | 09:42 |
maxamillion | spevack: i don't think it does either | 09:42 |
skvidal | so, next question? | 09:43 |
maxamillion | please | 09:43 |
spevack | sure | 09:43 |
Action: spevack got smacked down! ;) | 09:43 | |
spevack | geppetto calls back a bit towards the content vs code discussion, with "What do you think about packaging 'mostly content' things, like firefox extensions or stuff from arg.gnome.org, etc." | 09:43 |
skvidal | 1. firefox extensions don't seem like content to me | 09:44 |
cwickert | me nether | 09:44 |
ixs | geppetto: Firefox extensions are code, specifically javascript. And most of them are open source and we should definitly ship then if they are packaged. | 09:44 |
ixs | I would know, I prepared an adblockplus package and it's all javascript. | 09:44 |
maxamillion | That's a big grey area ... but in my opinion if all the licensing is in line and the code are compliant with the guidelines, I don't see why it shouldn't be allowed | 09:44 |
skvidal | 2. packaging art that is not interesting b/c of the updates process is expensive disk wise | 09:44 |
notting_ | FF extensions is mainly just an issue of handling upgrades with xulrunner/FF changes - i don't see any issues with it | 09:45 |
Kevin_Kofler | Firefox extensions are definitely code. | 09:45 |
notting_ | art may be better served with some sort of browser or channel mechanism | 09:45 |
spevack | maxamillion: can you expand more on what is the grey area? | 09:45 |
Kevin_Kofler | For artwork, it depends. | 09:45 |
skvidal | I think if we want to have people have access to art.gnome.org - it should be via a tool to get them | 09:45 |
skvidal | that'd be much better for the user and for their disk space use | 09:45 |
Kevin_Kofler | skvidal: You mean like KDE's GetHotNewStuff? :-) | 09:45 |
skvidal | Kevin_Kofler: I mean like I don't really care | 09:46 |
Kevin_Kofler | Packaging wallpapers other than the default wallpaper sets is a bad idea. | 09:46 |
cwickert | I think artwork is ok too, as long as it's free. Of course we don't need to package every background image from art.gnome.org because they cannot really be maintained | 09:46 |
maxamillion | spevack: the content vs. code issue and how much code is needed to make the content combined with the code able to be distributed, considering that we don't ship content | 09:46 |
Kevin_Kofler | We'd end up with a neverending flood of wallpaper packages. | 09:46 |
Action: spevack nods | 09:46 | |
Kevin_Kofler | We need to draw the line somewhere. | 09:46 |
Action: maxamillion was trying to focus more on the question and not so much on the ff extensions "example" portion of the question | 09:46 | |
Action: skvidal looks around for someone disagreeing | 09:46 | |
Action: skvidal notices no one | 09:46 | |
skvidal | okie doke | 09:46 |
notting_ | ... which leads into a corollary on fonts somewhere. although I don't think we're at the stage where we're overflowing with them yet | 09:46 |
ixs | geppetto: art? that would be pure content, right? That would clash with our current packaging guidelines. I do not know what exactly is on art.gnome.org. If it's wallpapers we shouldn't need to package them at all. If it's themes, grey area. Bug the packaging committee would be my suggestion. | 09:47 |
Kevin_Kofler | I think wallpapers are OK if they ship with upstream's packages (like kdebase-workspace, kdeartwork or the like) or if they're the default theme of a current or previous Fedora (duh). | 09:47 |
dwmw2 | I think it's best for us to ship software which can browse and install stuff from external content repositories (clip art, gutenburg, etc.). Much like yum does for software -- but why does it have to be in rpm form? | 09:47 |
Kevin_Kofler | Packaging other wallpapers is a rather bad idea. | 09:47 |
cwickert | Kevin_Kofler: a theme is ok, walpapers not. a theme is something that does develop over time, a wallpaper most likely not | 09:47 |
dwmw2 | I'd prefer not to distribute the content ourselves unless it's really _relevant_ to Fedora. Like at least the core fonts are | 09:47 |
notting (n=notting@redhat/notting) left irc: Nick collision from services. | 09:47 | |
Nick change: notting_ -> notting | 09:47 | |
skvidal | agreed | 09:47 |
skvidal | we're not packaging up project gutenberg, right? | 09:48 |
skvidal | so let's trickle along | 09:48 |
skvidal | fedora, like life, is not a pony farm | 09:48 |
skvidal | you don't get everything you want out of it | 09:48 |
Kevin_Kofler | Themes which contain at least some XML or some code are more like something packageable. | 09:48 |
dwmw2 | but we're not going to do what Apple did and ban a gutenburg reader because you might be able to read a text-only version of the kama sutra with it :) | 09:48 |
ixs | dwmw2: I can understand the wish for having it as rpms as it is a single database describing what is installed on the system and makes system management easier. But a useful autodownloader could drop an xml file somewhere mitigitatin that issue. so yeah, good call on the downloader | 09:48 |
maxamillion | which brings be back to my statement, how much code combined with content will no longer make it considered content? | 09:49 |
skvidal | dwmw2: is it an ascii art kama sutra b/c that would be weird | 09:49 |
maxamillion | errr question* | 09:49 |
dwmw2 | ixs: yum plugins. Now run and hide before skvidal hurts you :) | 09:49 |
Action: ixs runs, fast! | 09:49 | |
ixs | :D | 09:49 |
skvidal | dwmw2: hahaha | 09:49 |
ixs | dwmw2: but then I want yum-plugin-gentoo to do my own compiling!! | 09:49 |
Kevin_Kofler | LOL | 09:49 |
maxamillion | oh jeebus | 09:49 |
skvidal | ixs: do-able | 09:49 |
skvidal | ixs: sadly | 09:49 |
ixs | DO WANT! | 09:50 |
ixs | :) | 09:50 |
ixs | spevack: next question? | 09:50 |
spevack | yep | 09:50 |
spevack | i think it will all get on to one paste. | 09:50 |
spevack | jreznik asks, "what do you want to do for better cooperation between Fedora teams (for example like one team is pushing some feature without waiting or even without no communication with other teams even it's underlying lib etc.)" earlier jreznik suggested KDE SIG viz. Desktop SIG was a good example, but feel free to comment on the general case or on other examples that come to mind. | 09:50 |
spevack | last word should be "mind" | 09:51 |
skvidal | yes | 09:51 |
skvidal | so I don't know what to say here | 09:51 |
skvidal | we want better cooperation | 09:51 |
skvidal | the 'how' doesn't really matter | 09:51 |
skvidal | but ultimately if a team doesn't want to play ball | 09:51 |
skvidal | but they are doing something important | 09:51 |
skvidal | and doing it quickly | 09:51 |
Kevin_Kofler | Indeed, better communication and cooperation is needed. | 09:52 |
skvidal | that team is going to have more success | 09:52 |
spevack | jreznik also notes PolicyKit/KDE issues in rawhide | 09:52 |
skvidal | b/c people pay attention to progress | 09:52 |
notting | i don't think dragging people together like two siblings before mom is really practical. remind people to communicate, sure. but trust people to be professional | 09:52 |
Action: skvidal notices it always seems like KDE is playing left-out .... | 09:52 | |
Kevin_Kofler | And indeed, the way the desktop team is forcing the new PolicyKit through is a problem. | 09:52 |
red_alert (n=red@id-als-docking-167.ethz.ch) left #fedora-townhall. | 09:52 | |
maxamillion | why so? | 09:52 |
Kevin_Kofler | (The "desktop" team I should say, it's really just the GNOME team.) | 09:53 |
dwmw2 | if the feature approval process doesn't handle that, does the process need to be amended? | 09:53 |
cwickert | comunication is the base, so we need to make sure that all important changes reach the other teams e.g by using fedora-devel-announce instead of fedora-devel only | 09:53 |
ixs | jreznik: Great communication is what we strive for (or at least should). But there's not very much FESCO can do to force people to work together except asking nicely. But I'm happy to repeatedly ask nicely for a good documentation of an api, so that e.g. the KDE guys have the chance to support Gnome-Centric developments. | 09:53 |
maxamillion | dwmw2: I think that would actually be a good direction to look at it | 09:53 |
notting | force? its' the first abi change in policykit since Fedora 8. | 09:53 |
skvidal | dwmw2: so we get two features submitted one that is "screw *desktop" and the other is "unscrew *desktop" | 09:53 |
Kevin_Kofler | maxamillion: The feature got filed before upstream work on policykit-qt for PolicyKit 1 even got started. | 09:53 |
skvidal | :) | 09:53 |
dwmw2 | :) | 09:53 |
notting | i could be wrong, but i suspect there's been other changes in KDE and its dependent ABI in that time frame | 09:53 |
Kevin_Kofler | Now jreznik started porting it himself. | 09:53 |
Action: maxamillion is going to play devils advocate on this one .... | 09:54 | |
dwmw2 | I'd like packagers to be able to take a more holistic view. If you break dependencies, you should be able to go and _fix_ them. | 09:54 |
maxamillion | Kevin_Kofler: so Fedora should slow down development because kde is lacking? | 09:54 |
Kevin_Kofler | notting: We don't go and change libraries also used by GNOME to incompatible versions without talking to folks from GNOME. | 09:54 |
dwmw2 | thankfully, provenpackers now _can_.... | 09:54 |
maxamillion | Kevin_Kofler: or is it that you want these considerations to be discussed beforehand? | 09:54 |
cwickert | maxamillion: it's not only KDE but everything except Gnome, that's a big difference | 09:54 |
skvidal | Kevin_Kofler: sure we do | 09:54 |
Kevin_Kofler | maxamillion: We can't force a new version of a shared component if not all users can use the new versions. | 09:55 |
skvidal | Kevin_Kofler: it's just that we have more gnome devels on hand to go and fix the problems | 09:55 |
skvidal | Kevin_Kofler: so it doesn't seem to happen as much | 09:55 |
maxamillion | cwickert: Right, so then this needs to be a consideration before hand, like in the approval process like dwmw2 suggested | 09:55 |
Kevin_Kofler | skvidal: "We" was KDE SIG there. | 09:55 |
skvidal | Kevin_Kofler: I think you're kde-centric worldview has clouded your vision a bit :) | 09:55 |
cwickert | I completely agree with Kevin_Kofler, because this also affects Xfce and LXDE very much | 09:55 |
skvidal | Kevin_Kofler: look at things from a fedora-wide perspective | 09:55 |
skvidal | Kevin_Kofler: we need to fix deps-breaking everywhere | 09:55 |
Kevin_Kofler | skvidal: A Fedora-wide perspective has to include desktops other than GNOME as well. | 09:56 |
skvidal | we don't need to do it for one specific desktop or another | 09:56 |
notting | Kevin_Kofler: it was discussed upstream, starting six months ago | 09:56 |
cwickert | as long as all the new features add a dependency to a certain DE, I don't think this is a real progress | 09:56 |
maxamillion | I wasn't disagreeing with Kevin_Kofler, just trying to make a point as to where we need to look to fix the problem | 09:56 |
notting | Kevin_Kofler: are you saying that upstream KDE isn't watching upstream PolicyKit development? | 09:56 |
Kevin_Kofler | We can't just upgrade a shared component to a very incompatible version which is not supported by other users at all. | 09:56 |
skvidal | Kevin_Kofler: sure we can | 09:56 |
skvidal | Kevin_Kofler: in fact, we do it all the time | 09:56 |
skvidal | Kevin_Kofler: so saying 'we cannot' is just plain incorrect | 09:56 |
Kevin_Kofler | Upstream PolicyKit (which is mostly the same as the folks pushing the new versions in Fedora) is not talking to upstream KDE. | 09:56 |
skvidal | Kevin_Kofler: I think the problem is kde is not tracking it closely enough | 09:57 |
ixs | I think we've been always telling our contributors that we're a classless desktop and everyone is equally important, no second class desktops. I think it would be appropriate for any team driving a new feature to collaborate with the other stakeholders. Maybe it would be a good time reminding some people of this common courtesy. | 09:57 |
Kevin_Kofler | There's mainly one person working on PolicyKit in KDE (Dario Freddi). | 09:57 |
Kevin_Kofler | He's on the PolicyKit ML, but his requests for information about PolicyKit 1 got no answers at all. | 09:57 |
maxamillion | ixs: +1 | 09:58 |
Kevin_Kofler | Also because the documentation he asked for doesn't even exist. | 09:58 |
cwickert | skvidal: we *should* not. just think of the LiveCDs: Currently, the Xfce Spin comes with tons of gnome stuff and it's getting worse with every release: new gdm, policykit-gnome, ... | 09:58 |
skvidal | ixs: yes, b/c if we implement new createrepo features, for example, I really want to go chase down the apt and smart authors to make sure things don't go crazy for them? | 09:58 |
notting | Kevin_Kofler: he doesn't appear to have commented at all about the nwew policykit plan on the mailing list | 09:58 |
maxamillion | cwickert: +1 | 09:58 |
dgilmore (n=dgilmore@fedora/dgilmore) joined #fedora-townhall. | 09:58 | |
#fedora-townhall: mode change '+v dgilmore' by ChanServ!ChanServ@services. | 09:58 | |
Kevin_Kofler | There's poor to no documentation for the changes in the new PolicyKit, the little there is has been reverse-engineered from the changes required to port GNOME apps to the new version. | 09:58 |
skvidal | Kevin_Kofler: reverse engineereD? it's OPEN SOURCE CODE! | 09:59 |
ixs | skvidal: didn't you actually try that in the past with the common xml definition? | 09:59 |
maxamillion | skvidal: I don't see why not, why shouldn't we atleast ping with a common courtesy saying "hey, this is changing" or offer some sort of information outlet (RSS feed or otherwise) that those who might need to know could get the information | 09:59 |
skvidal | ixs: yes and what I found was the other maintainers didn't seem to care - until it was waaaaaaaaaaaaaay late and they wanted something offhand | 09:59 |
Kevin_Kofler | cwickert: +1 here too, we're also having that problem with the KDE spin! | 09:59 |
skvidal | maxamillion: we do - it's called a mailing list | 09:59 |
spevack | we're almost out of time, and I have one question left that needs to be asked. | 09:59 |
skvidal | maxamillion: and the code checkin rss feed | 09:59 |
spevack | then you can come back to this one if you like :) | 10:00 |
dwmw2 | spevack: go on | 10:00 |
skvidal | spevack: yes, please | 10:00 |
spevack | harish asks, "what do the candidates think about putting an effort to get eucalyptus or other cloud-related technologies into Fedora?" | 10:00 |
Action: skvidal gives a giant shrug | 10:00 | |
skvidal | I don | 10:00 |
maxamillion | skvidal: right, but where is the mailing list thread with discussion about PolicyKit 1 and other DEs? | 10:00 |
Kevin_Kofler | skvidal: "reverse engineered" in the sense that the documentation didn't happen as the changes were made (as it's supposed to), but people looked very closely at the source code, ported some GNOME apps and wrote a porting guide based on that. | 10:00 |
ixs | skvidal: sure there are always exceptions and other bad teams lagging behing. I'm not requireing you to wait years for them, I'm just saying that it would be common courtesy to talk about your planned features with the other affected people. It works for maintainers updating libraries, why shouldn't it work for devel teams? After all, I'm sure that the other desktop teams are not that bad... | 10:00 |
skvidal | 't see anything wrong with it | 10:00 |
Action: cwickert has no idea that eucalyptus is :( | 10:00 | |
Action: dwmw2 googles | 10:00 | |
geppetto (n=james@code.and.org) left #fedora-townhall. | 10:00 | |
skvidal | ixs: realy? ya think they aren't that bad? | 10:01 |
skvidal | ixs: seriously? | 10:01 |
cwickert | I think this cloud thing is only a buzzword | 10:01 |
skvidal | ixs: b/c I think everyone is that bad | 10:01 |
dgilmore | i think its fine to get it in to enable those that want it or need it to have it available to take advantage of it. | 10:01 |
ixs | skvidal: :) let's continue that later on, kay? :D | 10:01 |
skvidal | ixs: not really | 10:01 |
skvidal | :) | 10:01 |
dwmw2 | right, it's nothing special -- something that it's nice for Fedora to have, but it's not hugely exciting. | 10:01 |
dgilmore | I dont know why we would exclude something if there it meets our guidelines | 10:02 |
maxamillion | spevack: could we get clarification or an example of "cloud technologies"? the term is used to genericly and I was hoping for something more specific | 10:02 |
BeS (i=schiesbn@HSI-KBW-095-208-080-198.hsi5.kabel-badenwuerttemberg.de) left #fedora-townhall. | 10:02 | |
ixs | harish: cloud is great and cool and totally web-two-ohhish. If we have someone wanting to drive that as a feature, certainly. I'll happily help him get it through the feature progress and review his stuff time permitting. But it shouldn't be FESCO driving this feature forward. | 10:02 |
skvidal | maxamillion: planes :) | 10:02 |
Kevin_Kofler | http://open.eucalyptus.com/ | 10:02 |
maxamillion | skvidal: thank you | 10:02 |
spevack | Kevin_Kofler: i was about to post that, thanks | 10:02 |
skvidal | maxamillion: I hear zeppelins are making a comeback, too | 10:03 |
dwmw2 | http://news.bbc.co.uk/today/hi/today/newsid_8076000/8076805.stm | 10:03 |
skvidal | maxamillion: all the rage with the kids these days | 10:03 |
Kevin_Kofler | I'm not personally interested in it, but I also don't see why we would exclude it. | 10:03 |
maxamillion | spevack: wow, sorry ... i completely skipped that while reading | 10:03 |
spevack | the trolling on this question makes me laugh | 10:03 |
maxamillion | yes, I'd be for something like this .... pending it meets guidelines | 10:03 |
Kevin_Kofler | I think people interested in it should package it like any other cool new thing. | 10:03 |
spevack | and also makes me say "Townhall adjourned, thank you!" | 10:03 |
notting | what ixs said. i don't think fesco has directable resources it to throw at specific chunks of packages | 10:03 |
maxamillion | Kevin_Kofler: +1 | 10:03 |
skvidal | notting: what about the team of ninjas? | 10:04 |
Kevin_Kofler | I've read it has a lot of Java dependencies which all need to be packaged and license-checked. | 10:04 |
notting | skvidal: that's for enforcement | 10:04 |
spevack | Any final comments/thoughts/trolls from the candidates? | 10:04 |
spevack | since our hour is up? | 10:04 |
skvidal | notting: excellent | 10:04 |
ixs | Kevin_Kofler: right. eucalyptus is just another package with dependencies. Get it into fedora, if it will pass review. | 10:05 |
skvidal | spevack: I am spartacus | 10:05 |
Kevin_Kofler | So it's going to be hard to package that particular implementation, but that shouldn't stop people from trying. | 10:05 |
Action: stickster notes that there is another town hall in ~11 hours, same bat-channel, to accommodate other $TZ's | 10:05 | |
dwmw2 | I'm pleased to see we have a full complement of candidates -- it shows that people are actually interested in what FESCo does. | 10:05 |
spevack | Ok -- thanks to everyone for their time. Remember kids, "if you don't vote in the Fedora Elections, Chuck Norris will come to your house and beat you up" | 10:05 |
ixs | skvidal: THIS IS MADNESS!!!11 :) | 10:05 |
skvidal | dwmw2: or we just have a lot of suckers | 10:05 |
dwmw2 | ;) | 10:05 |
ixs | spevack: heh. thanks for running this session and channeling the questions. And sorry for your own question being shut down that fast. *g* | 10:05 |
dwmw2 | it's the anti-flag-policy party :) | 10:05 |
skvidal | ixs: different movie | 10:05 |
ixs | skvidal: sorry man. | 10:06 |
skvidal | dwmw2: I've got your flag RIGHT HERE | 10:06 |
ixs | *g* | 10:06 |
cwickert | spevack: thanks for hosting this meeting :) | 10:06 |
spevack | no problem. | 10:06 |
Action: dwmw2 burns skvidal's flag | 10:06 | |
ixs | cwickert: don't you wanna fly your nice red fedora flag? :) | 10:06 |
skvidal | dwmw2: my grandpa and your grandpa, sitting by the fire... | 10:06 |
dgilmore | dwmw2: thats not nice | 10:06 |
cwickert | ixs: no, as you know it's a violation of the logo guideleines and paul will hunt me down for that | 10:06 |
ixs | cwickert: but it would be ohhh so worth it. :D | 10:07 |
cwickert | ixs: let's see... ;) | 10:07 |
red_alert| (n=red@213.55.131.1) joined #fedora-townhall. | 10:07 | |
notting | spevack: thanks for hosting this! | 10:07 |