18:00:17 <ke4qqq> #startmeeting
18:00:17 <zodbot> Meeting started Tue May 31 18:00:17 2011 UTC.  The chair is ke4qqq. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:05 <ke4qqq> ok, so lets start out with an easy intro - candidates please intro yourself and tell us a little about you.
18:01:26 <ke4qqq> thats #1
18:02:08 <pjones> Hi, I'm Peter Jones.  I work in the Anaconda group at Red Hat.
18:02:21 <kylem> #1: hi, my name is kyle mcmartin, for the last few years i've been an employee of red hat working on fedora; specifically maintaining the kernel. prior to that, i did the same thing for ubuntu.
18:02:33 <iarnell> 1: okay, I'm Iain Arnell. An independent candidate, mostly involved with perl packaging.
18:02:33 <jforbes> I am Justin Forbes.  I work on virtualization and cloud bits for Fedora.
18:02:34 <sgallagh> My name is Stephen Gallagher, and I've been a Fedora user since FC2 and Red Hat Linux before that. I'm the lead developer on the System Security Services Daemon.
18:02:50 <nirik> 1. Hello everyone. I'm Kevin Fenzi. I've been on fesco it seems like forever. I've been chair for a while trying to keep things running smoothly and keeping fesco open and communicating well with everyone.
18:02:55 <sgallagh> I am also a Red Hat employee, for the record.
18:03:31 * nirik is also now a RH employee, leading our Fedora infrastructure. </disclosure>
18:03:41 <t8m> #1 - Hi, I am Tomáš Mráz, Red Hat associate for more than five years mostly working on maintenance and development of security related packages. I was Red Hat Linux user from the days of RHL 6.2.
18:04:03 <notting> 1. Hi, I'm Bill Nottingham. I've been working on Fedora for the rough equivalent of 'forever', and Red Hat Linux before that. I am a RH employee, and my dayjob is assorted technical leadership things. I'm upstream for initscripts and a couple of other tools, and I maintain some other Fedora packages that aren't part of my day-to-day work.
18:04:27 * pjones has also been working on Fedora and RHL since the land before time.
18:04:53 * notting resists urge to call pjones 'spike' or 'littlefoot', then
18:05:00 <pjones> heh
18:05:00 <ke4qqq> 2. Tell us how you see the role of FESCo, and whether you see a future that is different regarding the role of FESCo
18:05:31 <notting> <procedural note> are we doing free-for-all?
18:06:20 <ke4qqq> notting: you don't need permission to answer, the people in -public can ask whatever. and I'll queue them up.
18:06:52 <sgallagh> 2) The current role of FESCo is to execute the vision of the Fedora Board, guiding package inclusion and, where possible, development to achieve those goals
18:06:56 <nirik> 2. FESCO handles the details, the day to day technical stuff that keeps fedora running along. I don't see that changing too much off hand. I wish we had more time/energy to be more proactive and handle some things sooner, but absent something like Fedora Engineering Services really taking off, we can only manage when things get to us.
18:07:44 <iarnell> 2. I guess they are our benevolent overlords. Keeping things in check when necessary but not getting their hands too dirty. Been doing a great job so far, and I don't see much need for things to change in the near future.
18:07:52 <pjones> 2. FESCo's roll is to handle the technical aspects of making Fedora happen, and to help set technical direction.
18:07:55 <sgallagh> 2) I'd like to see FESCo given a discretionary fund to use for enticing contract development work to improve our ability to direct the technical face of Fedora.
18:07:59 <kylem> #2: FESCo plays an important role in helping set the technical direction of the project, provide guidance where it can, and work towards achieving the goals set out by the Fedora project board. In general, it's been effective in some ways, and lacking in others, usually as a result of busy schedules or limited manpower.
18:08:01 <jforbes> 2. Steering is an important word there, and I see the role as steering the development of Fedora along the right path.  It is easy to point in one direction and go, but there are a large number of little curves in the path toward a release that FESCo can help guild the Fedora developoment community through
18:08:14 <t8m> 2. I think the main role of FESCo should be in resolving the conflicts in Fedora packaging and release process and that is its main role currently.
18:08:49 <jforbes> err guide, not guild
18:08:54 <notting> 2. FESCo is abitration, information, and standards setting (obviously with things delegated to FPC, FES and similar roles). I'd like to be more active with developing towards the Board's goals, however, without directable resources, it's mainly limited to setting standards that encourage them, rather than developing new code in those directions.
18:09:36 <ke4qqq> #3: What sort of support do you  plan for mobile devices (Fedora on Droids,  'pads', phones, etc.)
18:10:46 <kylem> #3: That isn't the mandate of FESCo beyond making sure people working on such projects and spins get a fair crack at things, aside from providing them with technical guidance when they submit features for a release.
18:10:48 <pjones> 3.  That really depends on the Board's vision, to be frank.  It's up to them to set the non-technical goals of the project, and up to FESCo to execute on that direction.
18:11:11 <notting> 3. Well, first, we'd likely need a functioning ARM port (which is being worked on as a secondary arch). Aside from that, it goes back to directable resources - I'm all for Fedora having a space for those that want to work in this area, and I would encourage such groups. It's hard for FESCo to set a goal of 'we will work on all tablets that are released' and follow through, though.
18:11:23 <t8m> 3. I am not quite sure that Fedora as distribution should be targeted at mobile devices, but it could surely target the developers that want to work on projects targetting the mobile devices.
18:11:28 <nirik> 3. I think we can't directly do much here, other than encourage upstreams to add support. I think the fedora arm efforts are great, and we should add/help them where we can. Failing that we should make sure our desktops try and support syncing to/handling these devices and perhaps see about qa adding in some testing of that to our tests. :)
18:11:47 <notting> 3. And my brain immediately jumps to all the fun technical details that would be required. But as an example, my phone has an embedded Ubuntu fork - it would be nice if this could be done with Fedora.
18:12:14 <sgallagh> 3) FESCo doesn't have the resources to drive adoption on such architectures at this time. At best, we can give an "atta boy!" to anyone working towards it.
18:12:14 <jforbes> 3. That is an interesting question, and one that I had not put too much thought into until recenly when there was a blog post about running Fedora on a Galaxy S.  Though I think the more suitable approach is Fedora running some of the cloud applications which mobile devices use
18:12:17 <iarnell> 3. I'm already struggling to get to grips with a little netbook - I have no personal interest in anything smaller than that. If somebody wants to make it work, I'm happy to see them try, though.
18:13:14 <t8m> 3. And of course supporting efforts for ARM as a secondary arch and other similar efforts seems to me to be a good idea.
18:13:20 <sgallagh> 3) Furthermore, as has been mentioned previously, this would require a significant amount of hardware-enablement work
18:14:07 <ke4qqq> #4: From FESCo's perspective what do you think that the challenges facing FESCo and Fedora in the next year or several years.
18:15:32 <sgallagh> 4) I think the biggest challenge is going to be maintaining mindshare. With certain other distros gaining significant user share, Fedora runs the risk of losing its relevancy. Many developers are moving to the distro that they see as having the most users.
18:15:33 <pjones> 4. First and foremost, the new updates rules still need diligence to ensure smooth operation and timely fixes.  It's still a young system, and that inevitably means it'll need some work still.
18:15:48 <nirik> 4. I think we have a lot of challenge balancing the fast pace of upstream development with trying to release a stable/usable distro. I think in general desktop usage will diminish in favor of smartphone/etc usage, so we should find out what areas are left and concentrate resources on those.
18:15:50 <t8m> 4. I think the biggest challenge in the next year or even just now is to keep the interest of package maintainers and even more importantly active developers to stay with Fedora.
18:15:58 <sgallagh> 4) Unfortunately, that distro (which I won't name) has made a number of questionable decisions, resulting in code developed for it not being easily portable to other distributsions.
18:16:13 <iarnell> 4. I worry a little about losing contributors. I suspect it may be hard to keep (or encourage new) developers if our default desktop is increasingly dumbed down.
18:16:28 <notting> 4. The Board has set objectives that strive for more ubiquity for free code & content; the challenge is how to accomplish that in the current rather cutthroat marketplace, in combination with computing moving to a more client & cloud model.
18:16:55 <notting> 4. From a more specific standpoint, the challenge is maintaining a robust community that fosters innovation instead of argument.
18:17:07 <sgallagh> 4) I believe that FESCo needs to make having Fedora be THE premiere development environment for Linux software be its primary focus
18:17:40 <sgallagh> 4) Tying into 3), one good way would be to encourage the improvement of tools that make mobile development more appealing on Fedora than on other environments
18:17:52 <jforbes> 4. I believe the challenges facing Fedora are the shift in computing models we are seeing, Fedora will have to evolve to maintain it's relevance.  FESCo has the challenge of trying to make things easier on the devlopers who will keep us moving at a fast enough pace, and still maintain strong testing and QA for a stable distribution
18:18:05 <kylem> #4: I don't think there's any identifiable challenge facing us in the future, I believe given the level of support and volunteers we have right now, we've done a remarkable job keeping pace with upstream development while still providing a fairly good level of support for downstream users. Making sure we continue to improve upon it should be our main goal.
18:18:17 <nirik> 4. I think focusing on content creation might help us as well, as thats another area new devices are horrible at. Also, a stronger server focus so people who use an enterprise distro down the road can test out new great stuff first in fedora.
18:19:01 <ke4qqq> #5: Another question: will support for older Gnome  apps (such as nm-applet) that are useful in  'minority' desktops such as Fluxbox be continued?
18:20:07 <notting> 5. That's up to the upstreams invovled. In general, if you're trying to assemble your own desktop from random parts cobbled together elsewhere, you are at the mercy of your upstreams. If they move in a different direction, you either get to pick a different part, or take up maintenance yourself.
18:20:21 <t8m> 5. I think that completely depends on whether there will be package maintainers and developers that will support them. FESCo can hardly influence that.
18:20:59 <kylem> #5: Again, this isn't FESCo's concern, if someone feels like their upstream has left them behind, fork the old project and maintain a branch of it for seperately.
18:21:11 <jforbes> 5. I don't really think that is a FESCo question, something beyond the power of FESCo to mandate
18:21:23 <pjones> 5. That's really up to individual upstream (and package) maintainers.  If there are specific tools you want to ensure continue to be developed and supported, the best route, as always, is to become involved directly.
18:21:23 <iarnell> 5. I sincerely hope so - but it's more an issue for the spins/desktops/maintainers to ensure that something is done to keep "legacy" options alive.
18:21:39 <sgallagh> 5) FESCo needs to prioritize its limited resources on the core environments shipped with Fedora (mainly GNOME and KDE). I don't think we dare spread ourselves thin supporting other desktop environments to any great extent.
18:21:41 <nirik> 5. yes, it's up to upstream, but my understanding is that it is going to be supported for a while at least.
18:22:04 <sgallagh> 5) Naturally, we would work to facilitate such support if any upstream or individual contributor wanted to take that on
18:23:09 <ke4qqq> 6: Do the candidates feel that Fedora needs a larger  majority of users to facilitate a hold on  contributors, and if so what would be the best  strategy to increase Fedora's user share?
18:24:36 <nirik> 6. I don't think we should increase user share over all else. I do think we want to try and be an open welcoming community where possible. I'd like to see more efforts on making things easier for maintainers/folks trying to get things done. If we have that I think we will continue to grow people over time.
18:24:51 <pjones> 6. I don't think "facilitate a hold on contributors" is really the right idea.  Obviously we want as many developers as possible to be working on Fedora, but this isn't some sort of lock-in thing.
18:24:55 <iarnell> 6. I guess that most contributors start out as users; it's pretty obvious that the more users you have, the bigger the pool of potential contributors.
18:25:23 <sgallagh> 6) Yes. As I said before, the contributors will go where they think their consumers live. I stand by my assertion that our best move is to make Fedora the best platform for developing desktop, web-based and mobile apps.
18:25:32 <jforbes> 6. I think that the more we increase our user base, the more likely we will be to increase our contributor base.  Fedora has a strong draw for contributing users, and part of FESCo's job is to make sure it is easy to make the transition from user -> contributor.  Interestingly, contributors are also fairly good at bringing in more users and contributors.
18:25:48 <t8m> 6. I am not sure that the larger user share correlates significantly with larger number of contributors. It very much depends on what kinds of users are targeted.
18:26:14 <kylem> #6: Obviously we should always be working to grow our user base, and I think the marketing team does a fantastic job touting the virtues of every release with the release notes and such. I do think we need to place further emphasis on building contributors though, and not just encouraging people to look after their own personal projects, but to become involved in the project as a whole, and to increase the level
18:27:55 <notting> 6. Larger majority would imply we have a majority. In any case, I think that if we want to remain relevant in the long-term computing landscape, we shouldn't be shooting for a stable or smaller userbase. The best way to attack it is likely to design for the users we want - if we want to value free content/culture creators, design for them, etc. But a simple way is to design our default OS experience as a more integrated whole that excites people
18:27:55 <notting> to use it, as opposed to a random collection of bits.
18:29:38 <iarnell> 6. And it's important not to alienate existing developers/contributors. Even Linus was getting frustrated with our response in the 64-bit flash sound broken bug
18:30:19 <ke4qqq> 7: What is your perception of the state of auto-qa,  where would you like to see it go, and do you plan  to do anything to help it come to fruition?
18:31:20 <kylem> #7: I don't know enough about it to comment, in my experience though it seems to have done a fairly good job of testing things (At least, when I can bothered to click on the emails it attaches to my updates.)
18:31:33 <nirik> 7. I think auto-qa is great! I'm looking forward to it. I've suggested a number of tests for it and helped with resources on it. I'd like to see it get to the point where we run a lot of tests, not just the 2 live ones, and qa people can easily write and add more of them. Ideally someday a subset of them that make sense would be great to run on rawhide builds as well.
18:32:01 <notting> 7. It's better now than it was last year - it's on the right trajectory. I would love for it to continue to improve; automation is the best way to help with scant resources. I'd like to say I'd do all sorts of stuff to help it come to fruition, but I know better than to say I have that kind of free time. So it's likely more limited to helping with any roadblocks they encounter and bring up.
18:32:34 <iarnell> 7. At the minute, it's an annoying little child that keeps screaming for attention. But the problem really seems to lie with bodhi at the minute. We need to be able to notify maintainers of problems without spamming them to death with unnecessary "ok" mails.
18:32:36 <sgallagh> 7) AutoQA has been a great addition to Fedora. I'll do whatever I can to help it move forwards. I'd like to see AutoQA build a pluggable test framework that contributors to build regression tests in
18:32:40 <jforbes> 7. I think auto-qa is off to a good start. I would like to see it grown to include some test input from the package itself (and we discussed this a bit during fudcon this year.
18:33:01 <pjones> 7. I like auto-qa, and I think it's continuing to get better as it moves forward.  I look forward to helping fedora qa use it and other tools to improve the distro as a whole.
18:33:32 <t8m> 7. I'd like to see the auto-qa as the first wall for catching errors in the packaging. Of course there are many ways how it could be improved but it already is on a good way.
18:33:58 <iarnell> 7. But from what I've seen of the results themselves, it seems to be getting close to a point where it can really be used to enforce the most basic (i.e. don't break deps) requirements for any update.
18:35:37 <t8m> 7. I think its results must be waive-able and individual tests configurable per-package before it can be really turned on as an enforced wall.
18:36:20 <ke4qqq> #8: what do you see as the biggest process problem in fedora, (hopefully one fesco can address)
18:36:31 <sgallagh> 7) I would also like to see certain results (especially the rpmlint results) be waivable. For example, I don't need to see the same (wrong) spelling error notification every time I submit an update
18:37:57 <sgallagh> 8) There are no guarantees that Fedora N at EOL will behave the same way that Fedora N did at release
18:38:06 <kylem> #8: The biggest problem I see is that certain groups in the project still believe it's appropriate to ram in huge updates without any consideration at all.
18:38:07 <iarnell> 7. sgallagh. agreed for sure. Overiding rpmlint is something suse's obs has already managed for ages.
18:38:08 <t8m> 8. I think the package update QA process is still the biggest hurdle - the resources are too scarce for some of the hard-enforced rules.
18:38:19 <nirik> 8. Tough one. I think right now the updates process causes some people pain as they wish to make a update available for users who don't mind lots of changes. A features repo may help this pain point. I think we have a lot of abrt bugs that don't seem to be really dealt with, so something to help that would be good.
18:38:37 <pjones> 8. The hill for new contributors and new packages is still fairly high - the amount somebody has to learn to do to be an effective contributor is staggering, even when they're only contributing to packages they're already familiar with.
18:38:37 <jforbes> 8.. I think the feature process is a bit of a mess.  It needs to be more clearly defined and easy to navigate.
18:38:52 <pjones> jforbes: I think the feature process is a bit of a joke.
18:38:53 <nirik> 8. (agree with jforbes on that).
18:39:03 <sgallagh> 8) I think FESCo needs to facilitate having Fedora Branched be more stable during its development (rather than being Rawhide Lite), such that people who really want to try out new features can do so without having to backport them into stable Fedoras
18:39:50 <t8m> 8. And I agree with others that the feature process is messy as well.
18:40:05 <nirik> 8. Asking for and facilitating more communication between some developers and the rest of the community would be good too... some areas make changes very detached from the rest of the collection and I wish that would be improved.
18:40:24 <notting> 8. I think the biggest process problem is that many of our processes aren't integrated at all (the number of systems you have to be familiar with for packaging, build, updates, bugs, etc.); it's an incredibly diverse (not necessarily in a good way) set of tools. It also doesn't help that processes seem instinctively railed against.
18:40:41 <notting> 8. Which is not to say that other things mentioned here (features, etc.) aren't issues too.
18:40:45 <pjones> 8. nirik: yeah - the trick there is the facilitation bit.  It's not just providing a mechanism, but also putting a carrot on that stick.
18:41:31 <pjones> 8. notting yeah, the integration problem is part of what's driving what I said earlier about the staggering amount of work for new contributors.
18:41:35 <iarnell> 8. maybe the lack of a long-term-stable release every now and then - try to make every 3rd release "stable"  for and additional year or two, and allow the rest of us to keep living on the edge with the latest release.
18:42:24 <ke4qqq> 9: What is your perception of the state of auto-qa,  where would you like to see it go, and do you plan  to do anything to help it come to fruition?
18:42:29 <sgallagh> 8) iarnell: I don't think I agree with that. Stability is for RHEL. Fedora is the vanguard of Linux' future
18:42:34 <notting> 8. An additional one is that NFR + branched is a great process for helping have a stablizing release + a development stream, but is hampered by our lack of resources to effectively do that.
18:42:42 <pjones> ke4qqq: uh, wasn't that 7?
18:42:43 <sgallagh> 9) Didn't we already answer that above?
18:42:54 <ke4qqq> sgallagh: yes, sorry, copypasta fail
18:43:16 <ke4qqq> the real 9: What is your position on features that aren't quite  ready, or significant changes that occur just before  a freeze? For example, the glibc header issue that  occured days before final freeze, or F14's systemd  decision.
18:44:01 <kylem> #9: Well, the glibc header issue was a nice example of the process working correctly. The problem was identified and blocked at the updates-testing stage. (Ttbomk, the update still isn't even in f15-updates)
18:44:24 <pjones> 9. Well, the glibc change was obviously the wrong thing to do right at the end of a development cycle.  But it's indicative of a larger problem - there's very little incentive to get features in at the beginning of a cycle, and our schedules tend to be set up to encourage exactly the opposite behavior.
18:44:33 <nirik> 9. We have to be tough, but fair. In that case the change was reverted (rightly so). Our process worked there as the update got -karma to never go to stable. In other cases we may have not made the right choice (like python landing right before freeze, etc). It's hard to know in advance... but we do the best we can deciding such things.
18:44:33 <iarnell> 8. sgallagh, but we keep hearing that everyone wants stable releases but everyone else wants plenty of updates. And EL is stable for too long for our purposes. We should be able to offer some kinds of 2-3-year stable middle ground
18:44:35 <sgallagh> 9) You can't always see the future. In the case of the glibc header change, I think it was handled just fine.
18:45:00 <notting> 9. The glibc thing was obviously a bad idea, and I think we worked well in getting that pushed back. Not sure how we improve that without a full gatekeeper role which we don't have the resources for.
18:45:06 <pjones> 9. no-frozen-rawhide can help that some, but there needs to be more incentive to have bigger changes sooner, rather than later.
18:45:22 <sgallagh> 9) The systemd in F14 issue was a failure in planning. It should not have been approved in the first place for inclusion with so many glaring issues.
18:45:25 <notting> 9. A counter-example would be NM in F-15, where we brokered a solution for GNOME and KDE, but broke sugar b/c we weren't aware of the dependencies.
18:45:40 <nirik> 9. This also gets back to increasing communication... it would be great if the glibc folks were more tuned into what part of the cycle we were in, and communicated changes before landing them. (not to single them out, just an example :)
18:45:55 <t8m> 9. I thought that the early branching of a release from rawhide would help with these issues - that people would have a place where to develop new things. However for that the rawhide must be kept at at least partially usable state.
18:46:05 <sgallagh> 8) iarnell: While I agree it would be nice for our users, we don't have the level of interest among our contributors to accomplish that. EPEL alone languishes as it only has a dozen or so committed contributours.
18:46:43 <iarnell> 9. Apart from being pushed to f15, the glibc thing was handled properly. It was properly reverted and left to mature in rawhide. The week before release is far to late to introduce changes like this.
18:46:43 <jforbes> 9. I think the "features that aren't quite ready" problem is one of the issues that needs to be addressed and much more clear in a revised features process.  Some things have been handled really well by FESCo, but some have been allowed to fester longer than they should. We need to provide incentive to get things in early, tested, and held off for the next release if they cannot be made ready
18:46:55 <sgallagh> 8) No one wants to do the long-term maintenance, because new features are sexier.
18:47:32 <sgallagh> 9) jforbes: This is exactly why I think we need to be redefining what Branched is
18:48:22 <sgallagh> 9) I believe that we should Branch Fedora N+1 from Fedora N, rather than from Rawhide. And then Branched should be maintained such that it is ALWAYS installable
18:48:26 <nirik> 9. An improved feature process that noted things that just are "by the way, we are doing this cool thing" vs "I need help with this gigantic change that affects lots of packages" would help this case as well.
18:48:55 <iarnell> 8. epel's not doing that badly - stable releases don't need too much work - just someone to apply/fix security updates. If anything, epel is too hard because it's too stable (hard to replace ancient versions of  mediawiki for example - that would be much easier to handle it lts fedora).
18:49:19 <sgallagh> 9) nirik: On a related note, I think changes in the first group should be accepted later, but the second group should have to be in EARLY
18:49:30 <t8m> 9) sgallagh, so you propose something like having parallel development lines and pulling features and upstream packages from one to another based on stability?
18:49:34 <sgallagh> 9) i.e. If they can't be done before Alpha, punt
18:50:31 <sgallagh> 9) t8m: That's a pretty fair description, yeah. Fedora N: stable. Fedora Branched: stabilizing. Fedora Rawhide: experimental
18:50:49 <notting> 9. The biggest issue I recall having with earlier feature deadlines is you then have a cascade of different deadlines and it makes the feature planning pretty horrific (and hard to explain to the laypackager). furthermore, it likely means from a practical standpoint we'd need to shift our schedule to align better with some of our upstream projects in this paradigm
18:51:47 <t8m> 9) sgallagh, I would like this model too however I am afraid that developers would not like it as it would increase the amount of work that they would have to do to get their pet feature to the stable Fedora
18:51:49 <sgallagh> 9) But with a more rolling development cycle with Branched and Rawhide like I've been describing, I think this becomes easier to manage.
18:52:04 <iarnell> 9. Oh yeah. BIG changes must come early (btw. expect perl 5.14 to hit rawhide some time soon.....)
18:52:27 <sgallagh> t8m: Well, the way I see it is that this way we'd be encouraging developers to live on Fedora Branched rather than Fedora Latest-Stable
18:52:58 <sgallagh> 9) t8m: Right now, choices are "Fedora N, stable, but I want feature F right now." or "Rawhide... I may lose data"
18:53:28 <t8m> sgallagh, then there would be a question whether anyone would be using the Rawhide at all and whether it state would not quickly deteriorate to a horrible mess
18:53:32 <iarnell> 9. Don't we mostly live on branched anyway? I've certainly been trying to come to terms with gnome 3 since alpha
18:54:08 <nirik> 9.) I'd like to see more effort to make rawhide day to day usable too. Perhaps Autoqa could help here...
18:54:41 <sgallagh> 9) t8m: I'm suggesting that Rawhide might become more of an experimental repository, rather than something intended (if rarely achieved) to be installable
18:55:19 * sgallagh wonders whether this discussion would be best held for an actual FESCo meeting at this point.
18:55:19 <ke4qqq> 10: What is the outlook of the candidates on theadvancement of Fedora towards Wayland, and how muchof a priority do they think it should be?
18:55:46 <pjones> 10.  Well, we already screwed that up pretty badly I think.
18:56:18 <pjones> 10.  I think our graphics maintainers are very competent, and we should let them do their jobs, which may well include Wayland at some point.
18:56:21 <sgallagh> 10) I'll admit to not having enough information on this topic to give a reasonable answer right now. So I'll punt on this question.
18:56:23 <nirik> 10. I don't think it's ready at all... when it is, we should move to it. ;)
18:56:32 <t8m> 10. I am not really sure about it.
18:56:54 <notting> 10. Not to repeat points ad infinitum, but I think this grossly overstates the ability of FESCo to push in this space. I have confidence that our current graphics maintainers will advocate any switch when it's appropriate. As a potential future direction, it certainly doesn't seem obviously wrong-headed.
18:57:26 <jforbes> 10. I am happy to leave that in the hands of our maintainers until they feel it is readty
18:57:43 <iarnell> 10. Don't really know. As long as X still works until wayland is usable, I'm happy.
18:57:50 <pjones> jforbes: at which point we can snatch it from them and take the credit!
18:58:43 <jforbes> pjones: FESCo doesnt get credit for anything, only blame :)
18:58:46 <kylem> #10: It needs to work before it can be considered. I believe we're still a long way from that.
18:58:49 <ke4qqq> we are almost at an hour - so 11: As a contributor to Fedora, what do you percieve as  the positive/negative things from having Red Hat as  a sponsor?
18:58:53 <sgallagh> pjones: shouldn't we be the better [wo]men and NOT steal credit like some Other Distros?
18:59:09 <pjones> sgallagh: I was attempting humor.
18:59:09 <notting> 11. It allows it to exist? Not to be completely glib, but ...
18:59:23 <sgallagh> pjones: I know, so was I :)
18:59:25 <kylem> #11: Red Hat provides equipment, manpower, money, planning, ... Fedora wouldn't be able to exist without it.
19:00:00 <notting> 11. I don't know how well Fedora would continue as a completely independent project without any RH involvement. However, the fact that our tools and processes are open should allow someone to conduct this experiment, if they see fit.
19:00:24 <pjones> 11. The positive is that RH brings all the things kylem and notting have said.  The negative is that sometimes that has a way of imposing direction.  But that's also not necessarily a negative, and in fact often positive.
19:00:25 <sgallagh> 11) At the risk of showing my (Red) colors, I think that Red Hat's backing of Fedora is its greatest strength. It provides financial and (more importantly) legal support for the project
19:00:34 <nirik> 11. They understand and appreciate fedora, which is amazing and great. ;) I'd love to have more sponsors like that.
19:01:13 <jforbes> 11 Red Hat provides a signigicant number of resources, financial and otherwise which go a long way to making Fedora what it is, without getting in the way of what the community wants whenever possible.  I can't see any real negatives to that
19:01:17 <sgallagh> 11) There are times that Red Hat is perceived (occasionally rightly) of interfering in development direction. Some contributors fear that Red Hat exerts too much control, but I've never really found that to be the case
19:01:20 <t8m> 11. I have to agree with others here. There would be no Fedora without Red Hat, at least not if no other at least similarly generous sponsor would appear instead of it.
19:01:40 <iarnell> 11. Red Hat is pretty damn important. As a sponsor, they can't really be equalled - we'd not amount to much without them. But since spinning fedora off as a community-based distribution, it's essential for the community to have input and not see the company as running the whole show.
19:03:39 <ke4qqq> we're at an hour - there are other questions in -public - feel free to answer them directly if you wish here or otherwise, I won't immediately close the minutes.
19:03:50 <ke4qqq> #topic FESCo Town Hall Meeting
19:03:52 <iarnell> 11. But I'm sure their commercial interests will always lead to long-term-stable fedora getting nowhere fast.
19:04:14 <jforbes> Thanks for putting this Town Hall together
19:04:24 <ke4qqq> if you have a closing comment, please feel free to make it now, I would personally like to thank you for taking the time to come answer questions, and for putting up with me as your moderator.
19:04:25 <sgallagh> ke4qqq: Thank you for moderating!
19:05:03 <nirik> Thanks to ke4qqq for moderating and all the excellent questions. :) Please remember to vote!
19:05:19 <t8m> ke4qqq, thanks for moderating
19:05:24 <notting> Thanks to ke4qqq for moderating, and thanks to those that came today and asked questions.
19:05:45 <iarnell> Agreed. Thanks ke4qqq. And everyone else for participating.
19:05:50 <t8m> Thanks all for the questions and please remember to vote.
19:07:17 * ke4qqq will close the logs in 57 seconds plus or minute a minute
19:09:54 <ke4qqq> #endmeeting