From Fedora Project Wiki

ctyler Welcome to the 2nd FESCo Town Hall. Here's the basic format: Questions may be asked by anyone in #fedora-townhall-public, and will be relayed to #fedora-townhall by the moderator (me!). Candidates will answer (and discuss) the questions there. 22:00
ctyler To begin, I invite each candidate -- in alpha order by nick -- to give a 1-line intro. 22:00
ctyler Wait, scrub the alpha order, just intro yourselves :-) 22:00
* skvidal says hi 22:01
maxamillion Hi, I'm Adam Miller :) 22:01
juhp Jens Petersen 22:01
* ChanServ removes voice from mdomsch 22:01
Kevin_Kofler I'm Kevin Kofler, KDE SIG member, Fedora contributor since 2007. 22:01
* ctyler notes you can be more verbose than just name, should you choose 22:01
nirik greetings everyone. I am Kevin Fenzi. I'm an Xfce maintainer for fedora (along with the excellent cwickert). I have been contributing to fedora for a long time. 22:01
dgilmore Im Dennis Gilmore, I try to do things that are unsexy 22:02
juhp I work on fedora-i18n and haskell-sig - also apac cvs admin 22:02
* ctyler awaits questions in #fedora-townhall-public 22:04
* Evolution (n=jperrin@centos/admin/Evolution) has joined #fedora-townhall 22:05
ixs sorry for chiming in late, my network link was down for a bit. 22:05
ctyler Since we have only one question (about bacon), what if each of you gives a brief outline of your goals/plans should you be elected? 22:05
maxamillion ixs: you didn't miss anything, that is the first question 22:06
ixs good morning everyone. I'm Andreas Thienemann, packager, provenpackager etc. running linux for ages etc. :) 22:06
skvidal umm 22:06
skvidal wait 22:06
skvidal bacon? 22:06
* juhp finishes filing a webkit bug upstream 22:06
* rdieter ( has joined #fedora-townhall 22:07
ctyler First question: [0] are there any bottlenecks in the packaging workflow that fesco can do anything to ease? (inode0) 22:07
dgilmore i plan to work on alot of the same things i have been. secondary arches, buildsystem, infrastructure. I feel that they need to have a voice. I also want to encourage fringe fedora communities to be more involved and prominent. 22:07
nirik I have as usual many ideas (and not enough time for them). Some include: trying again to tackle merge reviews/review queue. Trying to get the fedora classroom more off the ground. Trying to improve overall end user support. 22:07
ixs okay. answering the question: I think the questionaire linked on Elections does a pretty good job explaining that for everyone pretty well. 22:07
* G_work (n=njones@nat/redhat/x-75d7ab4945f2dab7) has joined #fedora-townhall 22:08
Kevin_Kofler I don't think there are any real bottlenecks in the packaging workflow. 22:08
nirik I think there are, and we should try and work on them... but there is no magic bullet. We need to plug away at things and keep quality high. 22:08
maxamillion ixs: +1 22:08
juhp ixs: yes 22:08
Kevin_Kofler Buildroot overrides can be annoying to deal with at times, but other than that, the real problems making packagers' work hard are other ones. 22:08
juhp nirik: agreed - there are a lot of review and old merge reviews even that are just sitting around in limbo 22:08
Kevin_Kofler Like that proposed (passed, then put back for discussion) policy for country flags. 22:09
ixs To recap: I'd like to see Fedora focus on technical excellence and put less focus on politics and implementing new rules. I'd like to give some strength to the non-desktop related use cases and help supporting the new focus on QA. And last but not least, I'm planning on influencing the future Fedora direction. 22:09
maxamillion One thing I would like to add that I did not include on the questionaire is that I would like to iron out policies on what FESCo's role is in blocking and not blocking code and/or content 22:09
Kevin_Kofler Forcing us to diverge from upstream for no good reason puts more work on us. 22:09
Kevin_Kofler The packaging workflow itself is already fairly streamlined. 22:09
nirik Kevin_Kofler: although to be honest, it was never brought to enforcement, so it didn't really increase anything but fedora-devel mailing list postings and perhaps some blood pressure. ;) 22:10
ixs to the bottlenecks question: Our real bottleneck in the packaging workflow is the time packages spend in the queue waiting for review. FESCO can try to increase our number of reviewers but it is a problem fedora has faced for some time now. I'm not sure if there's an easy and quick remedy. 22:11
juhp I would like to work on keeping rawhide a bit more stable and usable, providing i18n guidance on docs, translations, etc 22:11
nirik ixs: its gotten better. The real monkey there is the merge reviews filling up the queue. ;( 22:11
Kevin_Kofler ixs: You make a good point there. 22:12
dgilmore ixs: very few of the problems fedora faces are simple ones to fix 22:12
Kevin_Kofler It's particularly annoying for some kinds of packages. 22:12
ixs nirik: yes, I'm including these in the "packages being in the queue". And there are specific merge review related problems again such as a few famous "Looks good, approved" reviews which give the merge reviews a bad name... 22:12
Kevin_Kofler For stuff which is a dependency of a newer KDE, it takes just a bit of nagging on #fedora-kde to find a reviewer. ;-) But more niche stuff can sit in the queue for ages. :-( 22:13
* nirik nods, waits for the next question. 22:13
juhp I am not sure if the question is just referring to package reviews? 22:13
ctyler Ok, I'm going to introduce another question, but just in case there's some network lag or I haven't left enough time, please use question numbers [0], [1], ... to clarify if you're replying to a previous question. 22:13
ctyler Next question: [1] Evolution asks: how do the candidates feel about the apparent drive toward gui controls to make the system easier to use, vs focusing on the fundamental cli capabilities? 22:13
maxamillion I think that GUIs are not the plague that a lot of people feel they are, but as a prefered cli user I would like to see more effort put into having both a GUI and a cli rendition of each of the "core" utilities 22:14
skvidal given that all the interfaces for the gui controls are being tied through systems which can have a cli interfaces, too 22:14
skvidal I don't think it is a problem 22:14
nirik 1: I like having the gui controls, but I really think we should try and allow command line/other control of things. It's hard to do that sometimes however, as those doing the work are not interested in cli interfaces. We can only try and get someone to work on such... 22:14
Kevin_Kofler I think it's a good trend, but we need to be careful not to focus exclusively on GNOME with our innovation. 22:14
skvidal evidence of this in the cli-interface for controlling networkmanager 22:15
dgilmore i think gui tools are something that newer users especially those from other os's expect. i dont think they should prevent you from doing it via command line tools and vi if thats what you choose ( its what i usually choose) 22:15
juhp [1] overall I think it is a positive and useful trend and inevitable if we are going to broaden our user base - as long as the cli capability is still there 22:15
Kevin_Kofler At least KDE, XFCE and LXDE need to be taken into account too. And let's add Sugar too, just for fun. 22:15
* nirik packaged up cnetworkmanager for that very reason. 22:15
* juhp thinks im-chooser is a good example 22:15
Kevin_Kofler The non-GNOME spins should not have to include GNOME apps to get basic functionality. 22:16
ixs Evolution: I'm all for trying to offer a consistent desktop experience. It's important that users, especially inexperienced ones are able to work and change their system settings without dropping back to a shell. I do consider it imperative however, that we do offer commfortable CLI commands for interfacing with system services such as dbus, policykit, packagekit etc. 22:16
maxamillion Kevin_Kofler: might even need to consider the moblin-ui before long as we are in discussion about it 22:16
maxamillion just a thought :) 22:16
ctyler Next, from mdomsch: [2] does Fedora suffer from an abundance of "groupthink", especially with regards to FESCo-related activities? Is there room for dissenting views, and are they given proper weight and consideration? 22:17
ixs Evolution: so in short, GUI hell yeah but please do not compromise on the CLI. 22:17
* ctyler thinks, Perhaps an interesting question considering the relative consistency of answers to the preceeding one :-) 22:17
ixs hehe 22:18
skvidal [2] no 22:18
dgilmore Kevin_Kofler: i do think we need people to do upstream development on tools 22:18
juhp interesting question 22:18
nirik 2: yeah, to some extent there is. I hope we will see some fresh views from this next fesco. On the other hand, this is a technical body, so many of the views are logical and reasoned, so perhaps that won't change (of course I guess I am saying I am logical and reasoned. ;) 22:19
Kevin_Kofler I think that we do have a problem where FESCo isn't diverse enough. 22:19
juhp [2] I think perhaps sometimes 22:19
Kevin_Kofler It mostly shows when some almost-consensus seems to form on the mailing list, but then FESCo votes the exact opposite. 22:19
Kevin_Kofler In statistics, this is a typical indicator of a biased sample. 22:19
maxamillion [2] I think it has in the past and with any luck, some new faces will show up on the scene and this can be altered 22:19
dgilmore [2] i think discenting views are given a fair hearing when they are not coming across as flaming 22:19
ixs mdomsch: [2] I would have liked to have seen more discussion in FESCO related to some of the more controversial discussions. While our contributors on -devel-list were pretty much devided on the issues, the FESCO logs in some cases show a list of +1s with very few discussion. It might be that they know better than the other maintainers but somehow I doubt it. 22:20
Kevin_Kofler maxamillion: +1, vote for different people in this election, not the same ones who have always been there! :-) 22:20
juhp :) 22:20
maxamillion Kevin_Kofler: well, also ... I don't want people to vote different purely for the sake of change but because they like what we have to say and like our ideas 22:21
ixs mdomsch: [2] So I'd say there's certainly danger of FESCO showing some groupthink, but that's not completely able to be elilminated. After all, while we're all a rather diverse group of people we've all come together in fedoraland and remarkably show quite a lot of similar opinions. :D 22:21
nirik many of the devel "discussions" haven't ever reached any consensus I don't think. The same 5 people yelling at each other. :( 22:21
Kevin_Kofler I also agree with ixs that more discussion within FESCo should be needed. 22:21
dgilmore [2] some things considered contriversial i think are largely considered that way due to cultural differences between the wide range of countries represented by fedora. I think its a hard thing to know that something is controversial to some people. but that it needs to be adressed when it comes up. We also need to embrace our differeneces as it helps define us 22:22
Kevin_Kofler nirik: Then we should have a tight vote in FESCo, yet it ends up decided with a huge margin. 22:22
Kevin_Kofler An artificial trend is also typical of a biased sample. 22:22
ixs maxamillion: yeah, good point. We mentioned that earler today after the first discussion: This terms candidate pool is much more diverse than the last time. So it might have been just coincidence that the current FESCO is similarly aligned. 22:22
nirik Kevin_Kofler: not following. If 5 yelling people are yelling on the list, how does that say that fesco should have a close vote? 22:22
* stpierre (n=stpierre@lopsa/tech-team/stpierre) has joined #fedora-townhall 22:22
maxamillion Kevin_Kofler: well, there are constantly a few that obstain from voting, that can make the results look heavy one direction 22:23
maxamillion Kevin_Kofler: just something to keep in mind :) 22:23
ctyler Next: [3] a followup from mdomsch related to [1] -- is it appropriate to hold out technology from Fedora until such time as both GUI and CLI are available for it? (examples: from mdomsch: networkmanager-cli didn't exist when NetworkManager was made default, legacy network service was still present though; from zcat: in f11, only gnome has a gui app to toggle touchpad tap2click. kde and others must either edit some hal xml, or run their own script 22:23
ctyler postlogin). 22:23
nirik I do agree more discussion is good though... 22:23
* nirik notes perhaps a requirement of adding a reasoning to any vote. 22:23
Kevin_Kofler nirik: [2] I haven't seen "5 yelling people" in the contentious discussions, but rather a lot of divergent opinions. 22:24
nirik 3: no. There is no way fesco can or should enforce something like that. All it could do is forbid. 22:24
maxamillion [3] - I don't necessarily think a technology should be excluded but I do think a gui and cli version should be encouraged. In terms of NetworkManager, there is still a cli "alternative". 22:25
Kevin_Kofler Re [3], if it actually regresses the CLI compared to previous Fedoras, yes it should be out. 22:25
nirik Kevin_Kofler: I looked at the dontzap thread and there was one guy that posted about 40 times. Thats not a reasoned argument, but argument by volume. ;( 22:25
skvidal [3] No 22:25
juhp [2] +1 to more discussion too 22:25
maxamillion The gnome having tap2click gui app is somewhat of a DE vs DE feature set issue and I think that's bigger than FESCo 22:25
skvidal [3] you cannot wait for things to be perfect to be released 22:25
Kevin_Kofler Just as we shouldn't allow technologies in if they break KDE. 22:25
juhp [3] no 22:26
Kevin_Kofler skvidal: There's a huge room between being perfect and breaking somebody else's desktop (or server or whatever). 22:26
Kevin_Kofler Technologies must not focus exclusively on GNOME. 22:26
skvidal eyeroll 22:26
juhp though default and inclusion are rather different things 22:27
* skvidal wonders how long Kevin_Kofler is going to ride this one trick pony 22:27
dgilmore [3] i dont think we should hold things back. but we need to encourage development of cli tools, as well as we need to have peopel to write gui tools for KDE, XFCE and friends 22:27
ixs mdomsch: [3] I think a balance has to be struck. I'd like to see the focus not only put onto the desktop, as some features did in the past. But mandating that we should force developers to come up with a -cli equivalent is not what FESCO should do in my opinion. It's free however to try to coax the feature developer to implement that. :) But what FESCO can and should do is take a close look at the Feature proposal an decided ... 22:27
ixs ... if it's ready for primetime. I think we've made the wrong call in the past some times and should have pushed back a few features to the next release. 22:27
maxamillion I will agree with Kevin_Kofler here in the sense that a new feature or technology shouldn't break another, but I would like that to be an over all thing as opposed to specific to KDE 22:27
Kevin_Kofler If some technology is shared between GNOME and KDE, you need to talk to both GNOME and KDE folks (including upstream) before upgrading it, and you need to make sure upstream support is ready in both GNOME and KDE. 22:28
Kevin_Kofler For stuff which also affects the console mode, like NM, there should be working console tools too. 22:28
Kevin_Kofler Thankfully that got fixed now with cnetworkmanager. 22:29
juhp right, important features should be ready enough for general use otherwise they should probably be tech-preview or something 22:29
maxamillion even though I understand Kevin_Kofler's drive to push the KDE issue in this situation, I would like that to be a blanket rule for other projects/technologies that work together 22:29
maxamillion or share a resource* 22:29
nirik the problem with that idea is that you cannot force a maintainer to do what you wish. :) 22:29
skvidal juhp: we're not rhel - no tech preview - sometimes you need things to bleed a bit 22:29
skvidal nirik: ding ding ding 22:29
ixs juhp: tech-preview? You got a RHEL background? :) 22:29
dgilmore Kevin_Kofler: comes back to needing more people who have an interest in fedora to be involved in upstream and to write new tools for other desktop environments 22:29
Kevin_Kofler maxamillion: Yes, this is not just about KDE, it's the same if the technology is shared between, say, XFCE and LXDE. 22:29
skvidal nirik: nor can you force upstream to care 22:29
nirik nor can you force them to keep allowing the old tech to be used, etc. 22:30
Kevin_Kofler One group can't unilaterally upgrade it without talking to the other one. 22:30
skvidal Kevin_Kofler: yes, they can 22:30
skvidal that's the whole point 22:30
juhp hehe - well maybe the word was ill-chosen 22:30
maxamillion Kevin_Kofler: right, I understand ... just wanted to clarify purely because I don't want to assume that all those in -public are aware of all current f-d-l happenings and debates that take place elsewhere 22:30
Kevin_Kofler Compat packages can help, but not for services like PolicyKit where the 2 versions can't talk to each other. 22:30
nirik I think fesco's job should be to urge cooperation and coverage, but we can't force anything. We have no power to do so. 22:30
Kevin_Kofler skvidal: They break things by doing so. 22:30
maxamillion nirik: +1 22:30
skvidal Kevin_Kofler: yah - you have to crack some eggs to make an ommelette 22:31
juhp anyway it is completely case-by-case in my opinion - it is really hard to answer this question in a general way 22:31
maxamillion skvidal: what does that even mean? 22:31
skvidal maxamillion: it means if you do much upstream devel work - you frequently have to break things to make REAL change 22:31
skvidal maxamillion: constantly maintaining compat with something else is significantly harder and slows you dow 22:32
skvidal n 22:32
skvidal a lot 22:32
maxamillion juhp: I agree with you there, but I think to a point that FESCo needs to write out policies/guidelines such that there aren't so many grey areas and "case by case" scenarios 22:32
Kevin_Kofler skvidal: So you want to turn Fedora into a GNOME-only distro? 22:32
juhp skvidal: we included ibus already in f10 that might be an example of a "tech preview" but anyway 22:32
skvidal Kevin_Kofler: wow, you are really beating this drum 22:32
maxamillion skvidal: I can agree with that, but I think the breaking and such should happen in a development branch, not in the stable space 22:33
juhp maxamillion: true 22:33
skvidal maxamillion: we have a stable space? 22:33
Kevin_Kofler skvidal: That's what you end up if you let the GNOME folks break APIs of the shared services at wish. 22:33
maxamillion skvidal: a release 22:33
Kevin_Kofler *end up with 22:33
skvidal maxamillion: what do you think rawhide is for? 22:33
maxamillion skvidal: that's what i'm getting at 22:33
ixs maxamillion: strong disagreement there: Common sense should prevail IMHO and not more specific rules. They will never be encompassing enough and you'll need a new rule, being more specific, granting specific exceptions etc. 22:33
dgilmore juhp: right i suggested that presto should first be released as a "Tech preview" disabled by default but there and avaibale for testing. sometimes we need to do that 22:34
skvidal maxamillion: are we breaking compat inside a release? 22:34
skvidal maxamillion: b/c I don't see ANY evidence of that 22:34
juhp dgilmore: exactly 22:34
maxamillion skvidal: I was under the impression that was what Kevin_Kofler's argument was about 22:34
dgilmore other times its much much harder to and we need to jump. thins break on landing :( 22:34
skvidal maxamillion: no - he's upset b/c policykit is making changes in rawhide that are hard for kde to follow 22:34
skvidal maxamillion: IN RAWHIDE 22:34
Kevin_Kofler maxamillion: My complaints are about breaking things from one release to the next, without waiting for various upstreams to support the new version. 22:34
maxamillion skvidal: ah, my appologies 22:34
ixs maxamillion: I fear we're not able to completely eliminate all grey areas. Our best chance is to rely on common sense and try to handle the cases where it doesn't work on a case-by-case basis. 22:35
maxamillion Kevin_Kofler: gotchya 22:35
Kevin_Kofler If things get broken by updates within a release, that's even worse! 22:35
skvidal Kevin_Kofler: but they don't get broken IN a release 22:35
dgilmore ixs: we need to avoid too many rules and allow common sence to guide us. otherwise we become to beurcratic and get nothing done 22:35
Kevin_Kofler Thankfully that doesn't happen often and never intentionally. 22:35
skvidal Kevin_Kofler: they break, in rawhide between releases 22:35
juhp ixs: yes 22:35
maxamillion Kevin_Kofler: which in my opinion are valid complaints, I was just misunderstanding the argument 22:35
ctyler Next up: [4] Do the candidates believe that a NON-AUTOMATED "official" comment TO EACH AND EVERY BUG like for instance "I looked at your bug report and i'm going to investigate it further" would be a good idea? 22:36
skvidal [4] absolutely not 22:36
ixs dgilmore: exactly my words. But I'm seeing a trend that some people are requesting more rules. I'm planning on taking a stand there. More rules will worsen our problems. 22:36
maxamillion ixs: I disagree, FESCo is here for technical purposes and those should be cut and dry in my opinon .... Does it meet guidelines? yes, let it in. Does it not? No, block it. ... its the guidelines that need rehashing in order to handle these grey areas.... but that's just my opinion 22:36
nirik 4. nope. I would love to get more bugzappers looking at tiaging, but thats not what this is proposing. 22:36
Kevin_Kofler Form letters without actual content are basically useless. 22:37
maxamillion [4] No, I agree with nirik on this one ... he just typed it first :) 22:37
dgilmore Kevin_Kofler: in networkManagers case we would have missed out on alot of new goodies. knetworkmanager still doesnt really support NM-0.7 properlly. sometimes we need to accept that. or we need to find coders that have a strong interest in fedora andKDE,XFCE, etc to manitain the tools for us 22:37
Kevin_Kofler It makes sense to have form letters explaining actions, but not to just have form letters for the sake of answering something. 22:37
Kevin_Kofler (i.e. for the sake of giving any answer, even a contentless one) 22:37
ixs ctyler: [4] OMFG no! It'll simply increase the noise ratio without adding _ANY_ signal at all. Our bug submission system is not mail-based, so a receiption receipt is not needed. A "Your bug was received" message, as offered by some mail based ticket trackers, is completely the wrong thing for our bugzilla and web-form focused approach to bugs. 22:38
maxamillion dgilmore: I think his complaint is more in the sense that there isn't enough communication or collaboration about the changes 22:38
juhp [4] I don't think it would be useful, no - not for each and every bug anyway 22:38
dgilmore [4] can be helpful. but needs to be genuine. 22:38
juhp some good generic templates might be good for some owners/packages - I don't think they should be used for ALL bugs though 22:39
nirik bugzappers already have some. 22:39
juhp right but inside bugzilla even 22:39
dgilmore [4] if it happened on each and every bug as it came in will give false hope of a quick resolution. but if you look at a bug and are a little stumped i think its nice to let the reporter know its being looked at 22:40
Kevin_Kofler dgilmore: [3] KNM's state right now is KNM's fault, but back in the day, NM 0.7 was rushed in after the feature freeze with no KNM available at all (not even an alpha version) and months before NM 0.7 actually got released. 22:40
nirik BugZappers/StockBugzillaResponses FYI 22:40
* ctyler notes that the question said non-automated 22:40
ixs maxamillion: I completely agree on not applying moral standards or any other arbitrary filter to packages in our repo: If they technically meet the guidelines, have been reviewed and passed, in they go. We both agree on that, compare the discussion this morning. I just do not think that we'll be able to detect every possible grey area in our guidelines and see to it being eliminated. Common sense and (quoting Mike I think) ... 22:40
ixs ... "Don't be an ass" will bring us a long way there. 22:40
ctyler From stickster: [5] Judging by some of the feedback on keeping up with certain technologies, it seems like there are SIGs that aren't getting the community support they need. Can FESCo make it easier for those SIGs to gather substantial communities that would help solve some of the issues they're experiencing, and if so, how? 22:41
maxamillion ixs: ah, ok ... I understand what you were saying, my mistake ... +1 :) 22:41
maxamillion [5] I don't so much see that as a FESCo issue so much as I consider it a community at large issue. Its possible that we could start to work more hand in hand with the Ambassadors and Marketing with their efforts to bring in prospective contributors 22:41
juhp ctyler: right but it also said all bugs :) 22:41
juhp which seems kind of a contradiction :) 22:41
nirik 5. I'm not sure how.. I would love to do so, but don't see any easy way. All fesco has really it's it's members. ;) 22:41
skvidal [5] fesco has no resources to allocate 22:41
dgilmore [5] stickster: most of it comes down to needing people to write new code and not package, bug fix old code. 22:41
ixs stickster: [5] It all depends on the SIG in question. By influencing policies and packaging guidelines support can be given to specific SIGs. e.g. working out a policy supporting finer grained dependencies is a possible bonus to the Appliance, Server and Robotic SIGs. 22:43
dgilmore stickster: we cant force anyone to work on anything. all we can do is guide. I think we need to try encourage those in upstream communites to try and be involved and keep an eye on fedora so that they can adopt new technologies and methods quickly 22:43
Kevin_Kofler Getting better support from the KDE community starts by not favoring GNOME all over the download page and other prominent places. 22:43
Kevin_Kofler In general, I think it depends on the individual communities. 22:43
Kevin_Kofler There's no one recipe which will work for all SIGs. 22:44
* nirik notes in general that better end user support could result in more contributors and help all sigs. 22:44
juhp [5] I am not sure what Fesco can do to help SIGs grown but if it could it would be a great thing :) 22:44
* skvidal is starting to enjoy Kevin_Kofler beating the kde-discrimination drum 22:44
ixs stickster: [5] For a games SIG however, that's not really likely to help much. But I do not see FESCO as a very hands on team. It's more about influencing people by asking them, advocating more communication between teams etc. 22:44
ctyler From Evolution: [6] should fedora filter applications like gnaughty for moral reasons similar to apple's filtering of the app store, or should it be strictly license/code quality based? 22:44
maxamillion Kevin_Kofler: I've actually thought you had a lot of solid concerns, but I don't see how our web presence should effect KDE upstream 22:45
maxamillion [6] No, there should be no intervention from FESCo due to moral issue, we are a technical entity and nothing more. 22:45
maxamillion s/we/they 22:45
* maxamillion needs to remember he is simply a candidate 22:45
skvidal no 22:45
ixs Evolution: [6] 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 ... 22:45
skvidal [6] legal/licensing issues only 22:45
Kevin_Kofler maxamillion: [5] If the download page calls the GNOME spin "desktop spin" and hides KDE behind an extra link, do you think this is a good first impression to give to KDE users? 22:45
Kevin_Kofler (I don't.) 22:46
nirik 6. I think there's a very slippery slope in filtering. We should avoid it where we can. This may also end up being a board question about what we should be filtering in what cases (and then back to fesco for a technical way to implement that) 22:46
ixs Evolution: people install on their computers. 22:46
Kevin_Kofler 6. No, we should not filter packages for moral reasons. 22:46
maxamillion nirik: +1 22:46
Kevin_Kofler Censorship is quite the opposite of freedom. 22:46
* skvidal rolls his eyes some more 22:47
dgilmore Evolution: [6] I think that we do need to make sure that kids do not have easy access to questionable content. but i honestly dont know how we can enforce any kind of controls. all we can do is make sure that those out there are properlly educated as to whats potentially avaiable. 22:47
Kevin_Kofler Yet freedom is what we stand for. 22:47
skvidal and we need to buy guns 22:47
skvidal lots of guns 22:47
skvidal to keep the gnome-loving MAN from taking our freedom away 22:47
ixs skvidal: Eric, is that you? 22:47
skvidal or something 22:47
dgilmore Evolution: [6]putting packages like gnaughty into its own repo would only make it more attractive to those who it is not really appropriate for. 22:47
juhp [6] I think that is something for the Board to decide - personally I don't we should encourage "immoral" packages in fedora since they are not a help to humanity 22:48
juhp don't think we * 22:48
ctyler From mdomsch: [7] Fedora has several types of contributors, which FESCo oversees to different extents. In the tech area, there can be both upstream code maintainers, and Fedora package maintainers, with some overlap. Please describe your qualifications as an upstream code maintainer, if any. 22:48
Kevin_Kofler skvidal: Quit accusing me of being repetitive, your personal attacks don't contribute anything to the discussion. 22:48
skvidal what personal attacks? 22:49
Kevin_Kofler I didn't even mention nor imply GNOME or KDE in my answer to this question. 22:49
skvidal You've converted me to your cause, clearly. 22:49
maxamillion Kevin_Kofler: the xfce spin isn't even mentioned on the main download page 22:49
ixs For the record: While the board would be the final authority on this, I do not believe it's a topic the board has to decide about at all. We have our packaging guidelines. Moral values or deferring inclusion questiosn to the board is not part of these. 22:49
dgilmore [7] mdomsch: im involved in koji, fedora-packager upstreams 22:49
Kevin_Kofler maxamillion: That also deserves fixing. 22:50
dgilmore mdomsch: as well as spacewalk 22:50
nirik 7. I don't do much maintaining upstream here (I'm mostly a sysadmin). I do help maintain a few packages... mussh, fwrestart, etc. 22:50
Kevin_Kofler maxamillion: Though the proportion of users of each desktop needs to be kept in mind for how prominently to feature it. 22:50
maxamillion [7] I'm not currently involved in any upstream development in terms of active development in adding their feature sets and such, but I send all my patched upstream for the packages I maintain 22:50
Kevin_Kofler [7] I do have KDE SVN access. I've been maintaining Kompare since I rescued it from bitrot for KDE 4.0.0. 22:51
skvidal [7] yum and createrepo are both used in a variety of distros. createrepo more than yum for the non-redhat-family-of-distros (fedora, rhel, centos, etc) 22:51
ixs mdomsch: [7] I'm certainly not the greatest coder all around as I simply lack the time to hone my skills, but I'm actively involved with some upstream projects partly based on the fact that I'm the fedora maintainer and partly just out of interest. Dracut would be one of the latter. And for other tools, more network management related, I'm the upstream myself... 22:51
Kevin_Kofler I also occasionally use my KDE SVN access to upstream Fedora patches. 22:51
* KB1JWQ (n=cchandle@nmap/user/KB1JWQ) has joined #fedora-townhall 22:52
Kevin_Kofler I also do upstream development in a few other projects, e.g. TIGCC. 22:52
Kevin_Kofler (That's a GCC-based toolchain for TI calculators with m68000 CPUs.) 22:52
juhp [7] I have worked upstream on releases of scim, xemacs, gtk2hs, etc and will do be doing some ibus work this year (probably others I can't think of now) 22:52
ctyler [8] What do the candidates see as areas (most/least) in need of change ? i.e. How should current processes or policies be refocused ? (either more/less attention) Priorities please? (from Cheshirc) 22:53
* skvidal starts his background drums 22:53
dgilmore [8] cvsadmin need to finally be automated 22:54
Kevin_Kofler FESCo needs to listen to the discussions on the fedora-devel-list more than it currently does. 22:54
skvidal dgilmore: I'll go you one better cvs needs to be shot from orbit 22:54
* dgilmore things that automating of repetitive tasks that can be should be done 22:54
skvidal dgilmore: getting us off of cvs and beyond needs to be very high on the list 22:54
juhp [8] I feel our web interfaces need to be unified for easy tracking and workflow of contributors 22:54
nirik 8. it's hard to say at this stage. We do need to make sure the feature process keeps moving along ok. I would love to see EPEL get into koji/bodhi. I am interested to see what the upcoming FAD day about devel cycles will bring us. 22:54
Kevin_Kofler We also need to stop saying "desktop" where we really mean "GNOME". 22:54
* ctyler notes 5 minutes left, 1 more question in queue 22:55
dgilmore skvidal: :) yes but the fundamentals of creating new modules and branches should be automated in a way that will transfer to a new VCS 22:55
Kevin_Kofler GNOME is A desktop, it's not THE desktop. 22:55
skvidal juhp: isn't that what fedora community is about? 22:55
nirik automating cvsadmin would be very very lovely. It's taken a lot of my time the last few years. 22:55
juhp skvidal: yep 22:55
skvidal dgilmore: nod 22:55
skvidal nirik: and you're a good man for doing that nearly thankless task 22:55
skvidal nirik: thanks 22:55
nirik you're welcome. :) 22:56
maxamillion nirik: wouldn't that be more of an infrastructure concern than a FESCo one? I am not against working with the infrastructure team, but just curious where the line is drawn 22:56
dgilmore nirik: indeed. you do an amazing job of it. it makes me feel bad for not doing it often enough 22:56
maxamillion nirik: +1 for all your cvsadmin efforts :) 22:56
nirik well, again FESCo has no resources of it's own but it's members. So, when we talk about priorities, it's basically what fesco members want to work on and get done. 22:56
ctyler followup from G_work: in re to: "<+skvidal> dgilmore: I'll go you one better cvs needs to be shot from orbit" how does FESCo propose to do this, it's been on the board for several release cycles now -- what would the candidates like to see done to improve fedora's security in the future? 22:56
ctyler whoa, scrub that 22:57
ctyler followup from G_work: in re to: "<+skvidal> dgilmore: I'll go you one better cvs needs to be shot from orbit" how does FESCo propose to do this, it's been on the board for several release cycles now 22:57
ctyler ^ use that 22:57
skvidal G_work: sadly the 'fix' is for one or more of the candidates to DO the work :( 22:57
ixs Cheshirc: [8] I see some potential for improvement in our packaging process: Review automation would do a lot to streamlining our review process as one example. But I think it is more important to improve the bi-directional communication between FESCO and the contributors. I had the impression that there's a growing amount of contributors feeling left out. 22:57
juhp nirik: karma +10 22:57
nirik the problem with replacing cvs is that it becomes the 'my VCS is better than yours' war. I think it will take some people who don't care which one to pick one, and implement it. 22:57
skvidal G_work: it is non-trivial - it is flame-causing and it is pain 22:57
skvidal nirik: as much as it pains me to say it - it's not a flame fest 22:57
skvidal nirik: it's git 22:57
skvidal git one 22:58
skvidal err 22:58
skvidal won 22:58
skvidal git won 22:58
skvidal the argument is over, we can move along 22:58
nirik thats fine with me. I don't care. 22:58
Kevin_Kofler IMHO CVS is working fairly well for us. 22:58
nirik anything is better than cvs. ;) 22:58
maxamillion i do, i think git is ass... but now is not the time or place 22:58
* mj0vy (n=mj0vy@ has joined #fedora-townhall 22:58
Kevin_Kofler I don't like git either. 22:58
nirik cvs has a number of nasty limitations. we have just hit another one recently: 22:58
nirik package tags can't begin with a number. 22:58
skvidal nirik: fun so 0xFFFF? 22:59
dgilmore VCS requirements need tobe gathered. then we should find the vcs that best suits those 22:59
Kevin_Kofler Git GUIs are all in various states of incompleteness, whereas Cervisia works great. 22:59
skvidal dgilmore: I'll bet you $20 it'll be git at the end of the discussion 22:59
ixs G_work: all our processes are cvs based for now and our processes are centralized. CVS works acceptable and I think our cycles are spent better on other topics. 22:59
dgilmore we should also be prepared to prove all vcs's are suitable/unsuitable in a test environemnet 22:59
skvidal dgilmore: nah 22:59
Kevin_Kofler Maybe we should just switch to something else centralized, like SVN? 22:59
Kevin_Kofler Then we don't have to redo all our workflows. 22:59
dgilmore skvidal: maybe so. but we owe it to everyone to prove it to be so 23:00
juhp I think we need to do some experiments with other SCM and once there is something better available and working people will want to move 23:00
skvidal dgilmore: no we don't 23:00
ixs G_work: changing all this would mean heavy lifting. But if someone volunteers, I'm all ears. I am just not proposing that FESCO starts doing the heavy lifting themselves. :D 23:00
skvidal dgilmore: ultimately the people doing the work owe NOTHING to ANYONE 23:00
maxamillion dgilmore: I agree with you on the test environment, we need to know it works before jumping ship 23:00
nirik skvidal: special cased I bet... or perhaps it's got some way around it. ;( the 389 packages are waiting for some fix. 23:00
skvidal dgilmore: the people USING the work - owe the folks DOING the work their thanks 23:00
ixs dgilmore: right! I'm sure I can come up with a lot of creative benchmarking to support or disprove of _ANY_ VCS. :) 23:00
dgilmore skvidal: :) 23:01
ctyler Ninth and final question: [9] Can you describe your activities / interactions with groups outside of Fedora proper, but still in the open source landscape? 23:01
nirik skvidal: oh, it's if there is a digit- in the package name. ;) 23:01
* ctyler gives 5 minutes overtime for last Q 23:01
skvidal [9] long ago I wrote parts of the nfs-howto, I work on yum and I worked to get all the pain split out and setup 23:02
dgilmore [9]: i was previously working on OLPC, though i helped to guide them to working inside fedora more 23:02
skvidal [9] I've been to a couple of the linuxfoundation face to face meetings to help with the packaging policy efforts - that's ultimately work and pain 23:02
nirik [9] I am very active with 2 of my local lugs here ( and as well as a local hackingsociety chapter ( I also am active with the local greyhound rescue group (have 4 hounds here). 23:03
Kevin_Kofler I already mentioned my involvement in the KDE project. 23:03
skvidal [9] also a while back I built a centos release and a number of their updates - (centos 3ish and couple of things for 4) (long before I worked for rh, for anyone from rh who might be listening) 23:03
Kevin_Kofler I also worked with small teams in the TIGCC ( and (TiEmu, TiLP etc.) projects. 23:03
maxamillion [9] I am currently the only Fedora Campus Ambassador and I work quite a bit to promote Fedora and open source as a whole among the community. I've developed some small utilities also for networking and sysadmin work which are now open source and available online 23:04
* nirik has also tested packages for centos folks. 23:04
dgilmore i did test centos5 for sparc 23:05
skvidal [9] I worked initially on func and certmaster and preupgrade and lots and lots of random other projects 23:05
Kevin_Kofler Most of what I did in the Free Software world was programming, and recently also packaging. 23:05
juhp [9] I work with input-method developers to improve input-methods of various languages (eg m17n). I work on haskell (recently testing shared library support coming in ghc-6.12) - formerly I was involved in emacs and xemacs development - I am considering doing nightly builds of chromium for fedora 23:05
ixs [9] This sounds a bit [7] related, so upstream related work would be one. QA and testing would be another one. But on a non-technical base, I've in the past helped to organize Akademy and GUADEC conferences, been contributing to documentation. On using open souce software: I'm involved in running a not for profit ISP on nearly 100% free software (exceptions are gpl violating embedded monitoring systems we have) and have some ... 23:05
ixs ... interesting insights into real world use cases. :) 23:05
ctyler And our Town Hall comes to a close! A big thank you to the candidates and to everyone who attended. Next Town Hall is for the Board candidates at 1400 UTC. 23:06
nirik I'd like to add I welcome any further questions from the community, either in any of the irc channels I am in, email or whatever. 23:06
ixs ctyler: thanks for running this session. 23:06
nirik thanks ctyler 23:06
* stpierre (n=stpierre@lopsa/tech-team/stpierre) has left #fedora-townhall 23:06
* ixs is heading to bed. stickster was right, it'S 5am... 23:06
* dgilmore is always available for questions 23:06
maxamillion ctyler: thank you for your time 23:06
dgilmore thanks all 23:06
juhp thank you 23:06
* Evolution (n=jperrin@centos/admin/Evolution) has left #fedora-townhall 23:06
ixs in case there are any further questions, please send them in a query or mail. 23:06
* mj0vy (n=mj0vy@ has left #fedora-townhall 23:06
ctyler Good night all. 23:06
ixs goodnight folks. 23:06
* edneymatias (n=edney@ has left #fedora-townhall 23:07
* Kevin_Kofler has quit ("Good night!") 23:07
stickster Thanks everyone, for doing this for the community. 23:07
* ixs ( has left #fedora-townhall ("n8") 23:08
* sijis ( has left #fedora-townhall 23:10
* MathStuf ( has left #fedora-townhall 23:10
* maxamillion ( has left #fedora-townhall 23:11
* marth ( has left #fedora-townhall 23:11
* tk009 ( has left #fedora-townhall 23:14