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 (n=rdieter@ip68-110-23-155.om.om.cox.net) 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@122.163.152.247) 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 rpm.org 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 (nclug.org and lug.boulder.co.us) as well as a local hackingsociety chapter (hackingsociety.org). 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 (tigcc.ticalc.org) and lpg.ticalc.org (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@122.163.152.247) has left #fedora-townhall | 23:06 | |
| ctyler | Good night all. | 23:06 |
| ixs | goodnight folks. | 23:06 |
| * edneymatias (n=edney@189.75.213.8) 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 (i=andreas@lacht.ueber.gattinnen-im-netz.de) has left #fedora-townhall ("n8") | 23:08 | |
| * sijis (n=sijis@adsl-70-131-122-68.dsl.emhril.sbcglobal.net) has left #fedora-townhall | 23:10 | |
| * MathStuf (n=MathStuf@c-71-58-177-177.hsd1.pa.comcast.net) has left #fedora-townhall | 23:10 | |
| * maxamillion (n=adam@li23-229.members.linode.com) has left #fedora-townhall | 23:11 | |
| * marth (n=marth@c-76-17-250-218.hsd1.mn.comcast.net) has left #fedora-townhall | 23:11 | |
| * tk009 (n=tk009@adsl-074-166-251-205.sip.bct.bellsouth.net) has left #fedora-townhall | 23:14 | |