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