18:01:05 #startmeeting FESCo Town Hall meeting 18:01:05 Meeting started Mon Nov 21 18:01:05 2011 UTC. The chair is jsmith. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:13 #meetingname fedora_townhall 18:01:13 The meeting name has been set to 'fedora_townhall' 18:01:26 #topic Introductions 18:01:41 Could the candidates please introduce themselves quickly, in the following order: 18:02:02 jforbes, limburgher, mmaslano, mjg59, mitr, j_dulaney 18:02:57 Hello, this is Justin Forbes. I started my involvment with Fedora in porting Fedora Core 1 to x86_64 and more recently have been focused on virtualization and the Cloud SIG 18:04:17 Hi, Jon Ciesla, maintainer of a wide variety of packages since 2007, with a slight emphasis on games. I have some dev and admin experience, and do packager sorts of things in my Dayjob as well. 18:04:34 (In order to speed things along, please type "eof" when you're done, and feel free to write up your answers in a text editor and copy/paste when it's your turn) 18:04:50 eof 18:05:50 hi, I'm Marcela. I'm using Fedora since FC-5. I work mainly as maintainer of Perl packages. I'm working for Red Hat five years as package maintainer. 18:05:52 eof 18:06:21 i, I'm Matthew Garrett. I'm a current FESCo member andwork onvariouskernel-related things in Fedoraincluding ACPI,EFI, power management and generally getting machines booted. 18:06:31 (+H) 18:06:31 eof 18:06:39 Hello, I'm Miloslav Trmač, a contributor since RHL times, used to do lots of localization and internationalization, for the last ~5 years mainly working on security-related projects at all levels of the stack. eof 18:06:46 My name is John Dulaney. I have been using Fedora since Fedora Core 1. I became involved with the Fedora Project a year and a half ago when I joined the QA team. I was one of the original Proven Testors, and have been involved in every release since F13. Recently, I've continued my role with QA and have also become involved with lending a hand here and there in other projects. I am also a Fedora Ambassador. I am a m 18:07:47 j_dulaney: Cut off after "I am a m" 18:08:04 Righteo 18:08:19 I am a music major at Methodist University, and I enjoy building model ships. EOF. 18:09:21 Awesome, looks like we have a great set of candidates. 18:09:25 #topic Questions and Answers 18:09:42 Now we'll ask the candidates a set of questions, and give them each a chance to respond 18:09:58 I'll rotate the order, so that each candidate gets the chance to answer first 18:10:16 If you have questions you'd like to ask of the candidates, please post them in #fedora-townhall-public, and I'll add them to the queue 18:10:37 Now on the first question: 18:10:50 Q from mizmo: Where would you like to see fedora in 5 years? (jforbes, limburgher, mmaslano, mjg59, mitr, j_dulaney) 18:12:26 In 5 years I would like to see Fedora continue to lead the way with new technology, and keep stability to the point that you aren't afraid to install it on your grandmothers PC. 18:13:12 I think we are working well toward that end, but one thing I would like to see is a slightly easier barrier to entry to bring more developers/packagers/testers to the community, without sacrificing quality. EOF 18:13:43 Pretty much right where we are now, but with more contributors across the board. We're not the biggest, or the most popular, but we're leading edge, we have a large catalog of great software, we offer a diverse set of spins for diverse use cases, and we're upstream for RHEL and it's derivitives. These strengths allow us to effectively lead the way forward for Free Software, and computing in general. 18:13:43 EOF 18:14:44 I'd like to have a stable platform for developemnt because things are now changing very fast. For example there is many clouds, desktop could be product aimed only for tablets, virtualization will be more common, ... So we should pay more attention to the core of Fedora. 18:14:46 eof 18:14:57 I'd like to see Fedora be usable by everyone. I want us to cater to developers. I want us to be usable for average home users. And I want us to be accessible to anyone who wants to involve themselves in contributing to Fedora. 18:15:06 The trick is to handle this without compromising our ability to provide technical leadership to the entire Linux community. I think we can achieve that, but it's going to include tweaking our processes as we gain a better understanding of what our barriers are. 18:15:10 eof 18:15:27 What really determines the future are "upstream" projects (even if some started within a Fedora infrastructure). I hope Fedora will still be an OS distribution for general-purpose devices. 18:15:29 I'd like Fedora to 1) be more appealing to technical users (e.g. not "freezing" published releases so much - many web applications improve more often than Fedora does), 2) provide a more consistent platform (with fewer components that do the same or very similar things), and 3) pay more attention to upgrades/migration from older technologies/releases. eof 18:16:00 In five years, I think that we will have Arm supported as a primary architecture since ARM seems to be the major up and coming hardware. I also see Fedora having the best software technology in the world 18:16:57 I would like it also continue to be usable by non-technical people (I actually did put F15 on my grandmother's computer, and she loves it) 18:17:22 Fedora should be the leader in technical innovation. 18:17:23 EOF 18:17:52 Q from thunderbirdtr: Fedora have wikipage some page have translation or information mistake , What will happen for these page? (limburgher, mmaslano, mjg59, mitr, j_dulaney, jforbes) 18:20:30 Assuming that I understand the question correctly, the page can be corrected fairly quickly. The beauty of a wiki open to people of many different languages and skillssets is that the wiki can represent a superset of the best of the available knowledge. If the page in question is protected in some way, that can be addressed with the appropriate team. If I'm misunderstanding, please point that out. :) 18:20:30 EOF 18:20:55 Sadly, nothing. Every page should have active owner who will update them or be responsible for them. I tried to fix some related to my work, but imho it's lost battle without more people interested in documentation. 18:20:57 eof 18:22:06 Bugs are bugs, whether they're in our packages or our documentation. The main difference is that we have less direct responsibility forindividual wikipages. 18:22:12 We could adopt a similar process for wiki pages as for packages, but overall I think that wouldjust serve as an unacceptable barrier of entry. 18:22:30 So really, I think all we can do here is maintain vigilence and encourage people to correct any errors that they find. Getting involved in documentation is a great way for people to get started in the project. 18:22:34 eof 18:22:40 The best way to fix translation mistakes in Fedora-maintained content and programs is to either report them at bugzilla.redhat.com (component "Fedora Localization"), or to became a translator and contribute the fix yourself (see https://fedoraproject.org/wiki/L10N ). eof 18:23:31 Since the only language I am fluent enough to be able to translate is Scots Gaelic, I don't know how much I'll be able to help with translation of Wiki pages 18:24:21 When there is an issue that you know exists, the best thing to do to lead to higher quality is to correct it yoursefl 18:25:10 If you think that the information is not accurate, then send a note to the page's creator/maintainer. EOF 18:25:14 I hope to see the localization team get these pages updated and correct, but I understand it is an ongoing issue with an everchanging wiki. Perhaps if we can attract more translators, the problem will be easier to tackle. 18:25:19 EOF 18:25:52 Q from gholms: What do you see as the biggest problem in Fedora? (hopefully one that FESCo can solve) (mmaslano, mjg59, mitr, j_dulaney, jforbes, limburgher) 18:28:26 I guess we have different views on what should be achieved. Some wants solid platform for development, some want the best desktop. FESCo could decide about some features or changes in Fedora. 18:28:54 Candidates should represent all groups,so everyone could happily work on their projects.. 18:28:55 eof 18:29:36 We're still limited in the amount of QAwe can perform.The enforced testing inode0 stable releaseshas improved things - the number of major problems hitting stable releases has decreased. But it's still not ideal. 18:29:47 Oh what on earth. 18:29:55 I'm sorry. Let me try this again. Something is very broken. 18:30:16 We're still limited in the amount of QA we can perform. The enforced testing in stable releases has improved things - the number of major problems hitting stable releases has decreased. But it's still not ideal. 18:30:44 Our processes make it harder for packagers to get their code into the distribution. That's the kind of barrier to involvement that discourages people from contributing. overall I think it's justifiable right now because the alternative is breakage, but we can do better. 18:31:07 AutoQA is an important part of this. If we have confidence that we can automatically determine that packages aren't going to break the world then we can reduce the human testing component and make it easier for packagers to push their updates. 18:31:11 eof 18:32:46 From a non-technical perspective: there are various groups that want to do very different things with Fedora (which should be quite possible), but they sort of talk past each other. As a result, technically, Fedora is slowly inching towards becoming a download.com: various upstream projects are collected - but we don't spend much time on choosing (or even creating) the best infrastructure pieces and promoting their use everywhere - we us 18:32:48 ually carry several variants, even within the set of very commonly used packages. eof 18:33:26 The biggest issue I can see is in knowing what is going on throughout the project, especially when it's things that effect the specific project one is involved in. The issue is that there is simply too much information, and the needed information is not always communicated directly to the people that need to know it. 18:33:28 A prime example is recently a package received a soname bump that was not announced, which could have potentially broken a bunch of other packages. We need to guard against this sort of thing. EOF 18:33:34 I think the biggest problem in Fedora is barrier of entry. You see it frequently with new packagers and developers who have great contributions to make, but find the process of getting involved too daunting. I hope to see that barrier lowered in a way that can maintai 18:33:37 n quality. I believe it will help us attract new contributors and more community. 18:33:45 When people are involved, be it as packagers, developers, testers, documentation, or anything else, there is a sense of pride in the distribution as a whole. This is key to keeping Fedora at the forefront of the technology curve, while ensuring we maintain stability. 18:33:49 EOF 18:33:52 Vision conflicts. Most of the flamewars and bikeshedding I've witnessed stemmed from either miscommunications or overlapping ideas about what Fedora should be. IMHO, if we can keep in mind that Fedora is and can be used for many different use cases, we can keep growing and expanding our capabilities without compromising our commitment to existing users. We can add choices, while choosing sane defaults. A great example of this is the sy 18:33:52 stemd migration. Some love it, some hate it, but at the end of the day I think it was well-handled, positive, and enables us to move forward without *too much* pain, because things like compatibility and a migration plan were considered. When conflicts arise, it's FESCO's job to try to bring everyone into the tent as happiliy as possible. 18:33:53 EOF 18:34:10 Q from cwickert: When it comes to approving new features: Are you willing to trust maintainers to do things right or are there features you'd never approve? If so, what kind of features and for what reasons? (mjg59, mitr, j_dulaney, jforbes, limburgher, mmaslano) 18:34:25 Ha. That's a good one. 18:35:16 In almost all cases, I trust the maintainers. In general the only time something should come up in front of fesco is either because the change is going to impact a lot of other maintainers, or because the maintainer wants to ask for advice. 18:36:23 There are certainly features I wouldn't approve, and an example is the gnome3 extensions by default feature proposal that was made last week. That was a feature that directly worked against the maintainer (and upstream) of another package. 18:37:03 Further, there are features like porting to FreeBSD, for example. If anyone wanted to do that in the context of the project, I'd say no. 18:37:18 It's a neat thing for someone to do. It's not a neat thing to use the project's resources on. 18:37:24 eof 18:40:13 There's no category of features that I'd fundamentally rule out. I am rather concerned about 1) doing changes thoroughly (see above re: duplicated infrastructure) and 2) providing a sane migration path, and I consider having a reasonable and practical plan for both a precondition to approving a feature. This also means that I'd likely vote against high-cost/little-benefit features. (There's also the question of "who will do the work" w 18:40:15 hen a large-scale migration is proposed - FESCo does not have much power to make anyone else do work.) eof 18:40:23 Maintainers generally get things right. The only exceptions would be something that breaks everything else that is unloaded without warning or something that would violate our core values (packaging an MP3 decoder, for instance). EOF 18:40:53 Yes, and yes. I do trust maintainers to do the right thing, though I can't say there wouldn't be features I would never approve. Features that work against Fedora as a trustworthy and stable platform for instance. 18:40:56 EOF 18:41:45 Mostly A, but there are certainly things I'd never approve, such as reversing our bundled library policy. Mostly, our maintainers have excellent judgement, but FESCO by definition must be prepared to think critically and say no when needed. If a feature greatly reduces Fedora's utility, needlessly breaks *nix/LSB/FHS compatibility, or is likely to alienate a large group of users, it at the very least needs to be reconsidered. That, and 18:41:45 I like the fact that yum upgrades often work. I've got a system that used to run Fedora 2. It's on 16 now. That's awesome. 18:41:45 EOF 18:43:42 I'd like to trust, but FESCo is here not to be nice, but decide technical difficulties. For example from my preivous year in FESCo I was against update of NM, because it broke NM for KDE and Xfce. Patches were proposed, but they didn'tfix it. Same thing with btrfs. Maintainer believed that it could be the main fs, but it doesn't have fsck. 18:44:20 I didn't approve anything which broke work of others. 18:44:30 eof 18:45:18 Q from gholms: What role do you want to see secondary arches take in future development? (mitr, j_dulaney, jforbes, limburgher, mmaslano, mjg59) 18:47:30 I think the current system is roughly fine - give architectures about which most of the project doesn't care much about the space in which to work on a Fedora distribution, and promote them to a primary architecture if the runtime quality is good enough and community interest is wirespread enough that we can ask any package maintainer to care about the architecture. eof 18:47:49 I would like to see ARM become a primary architecture. With the ARM-based servers HP is working on, we could port our entire build system to ARM 18:48:17 Which would make it very easy to do ARM builds as well. 18:49:33 ARM looks like it will be huge in the near future, and it would be good to have support for it. Besides, Fedora on a tablet would be cool. (: ORF 18:49:37 EOF 18:49:41 I have worked on secondary arches before, and I know it can be a lot of work. I would like to see secondary arches treated with respect in the fact that changes to primary arch packages are not likely to break things for the seconday, and when they do, the package 18:49:45 maintainers make a reasonable effort to resolve the issue in a timely manner. Ideally we should be supportive whenever we can, and never do anything to inihibit secondary arches. 18:49:49 EOF 18:50:34 Ideally I think it improves the health, vitality and flexibility of the distro as a whole to support more arches. Conceptually, at least, the more arches we support, the better equipped we are to support more in the future. I'd like to see more arches make the trip through secondare to primary. ARM is a good example of/candidate for this, but I have no objection to others (ppc, sparc, s390) if the quality is there, at least for secondar 18:50:34 y. That said, I think our primary focus needs to stay on intel, at least for the time being, but not to the exclusion of others. 18:50:35 EOF. 18:53:29 I'd like to see more architectures as primary and it's hard work for those working on ppc or arm. But I guess it's limited by our hardware, so number of primary probably din't change soon. 18:53:31 eof 18:53:56 Much the same as now? ARM's obviously an interesting case, since it's starting to move into the marketsthat Fedora has more traditionally been involved with. I'd expect to see it as a primary arch in the not-too-distant future. 18:54:16 I suspect that most of the other secondary arches are going to continue to be secondary. Having architectures maintained by a small number of individuals with little interest from external developersor the rest of the project doesn't scale well. 18:54:33 But that's really what the secondary architecture system is for. It lets people work onthe things they're interested in without holding up the people working on primary architectures. If there's enough interest they'll be promoted. 18:55:02 So, so far, it seems to be working as designed. I think it's a success story for Fedora, and I think it'll carry on playing that role. 18:55:05 eof 18:55:13 Q from j_dulaney: What can be done to be sure that Fedora remains at the technological forefront and yet continue to release a solid product? (j_dulaney, jforbes, limburgher, mmaslano, mjg59, mitr) 18:55:26 Hmm 18:57:51 I think that we need to be on the lookout for new technologies that can be packaged into Fedora. Sometimes there may be a good idea out there that doesn't have any exposure, and including it in Fedora may be a huge plus for the project as a whole. We need to maintain testing of new packages and continue to properly review them before they are accepted into Fedora. 18:58:54 Quality Assurance sure could use some help, too. When it comes down to it, I believe that there are only about ten people that actively test Fedora. That's a lot of work to be placed on just a few people. 18:58:56 EOF 18:59:02 I think the biggest thing we can do is attract more contributors, and stick to our principles on QA and testing. I know that autotest has helped quite a bit, but more can be done. If we can make it easier to become a contributor, streamline the process a bit, I think 18:59:07 we will attract more contributors across the board. People working on development and packaging to drive the technology, and testers, QA, and documentation to ensure we maintain stability and usability. 18:59:11 EOF 18:59:18 Keep up to date. This isn't just chasing new cool stuff like systemd, but keeping existing things up to date. A good example here is libpng. By incrementally moving to 1.5 and then 1.6, we're getting the software we ship patched. Then new software developed can take advantage of the new library, and upstreams and other distros can take our patches and improve the whole ecosystem. By doing this across the board, we can develop and main 18:59:18 tain the idea in the community that Fedora is a great platform for development, which will help strengthen our collection and broaden our user base. 18:59:18 EOF 19:00:38 We should still update our packages and bring new software. But we should pay attention what's got in. I don't think that new contributors will come because we have new popular apps like Firefox, but because we have good infrastructure, tools and people, which will help. 19:01:48 Also I don't want making new contributors too easy, some distributions are making more obstacles than we do, but they have good people with strong skills. 19:01:50 eof 19:02:22 I think AutoQA is the most important thing here. Our technological progress is irrelevant if nobody can use our releases because they break every two weeks. Human testing is great but inherently slower, and even then some things that break specific use cases slip through. 19:02:46 We've shown that we can maintain technical leadership. There was a period where other distributions seemed to be adopting our technologies before we did, and I'm glad we're past that now. Maintaining quality is the difficult bit of that. 19:03:16 Broken updates discourage users. Without users we don't have contributors. Without contributors we don't have technology. So we need to keep focusing on that. 19:03:19 eof 19:03:45 This is one of the most important challenges Fedora faces. I think, ultimately, for the "important" package we need maintainers that are more than packagers - maintainers that do the integration work that can only be done within a distribution and wasn't therefore done upstream; maintainers that work with upstreams on the best ways to use the Linux platform, helping them and persuading them if necessary; maintainers that handle bugs _in 19:03:47 Fedora_ instead of pointing bug reports at upstream. 19:03:49 Having more contributors would help, but the higher expectation of what being a "maintainer" involves is critical. 19:03:52 Also, don't forget that most of "quality" comes from upstream - if a program is fundamentally unsound or maintained by incompetent people, it will always be difficult for Fedora to build a solid product upon it, and Fedora has little quality to add to a very high-quality program. The "quality" which we should care about in Fedora is primarily quality of the integration work that is done _within_ Fedora. (As a consequence, package-specif 19:03:54 ic test suites really belong upstream, not into Fedora AutoQA). eof 19:04:43 Q from MarkDude: Beefy Miracle- do you see this as a help or a hindrance to promoting Fedora? (jforbes, limburgher, mmaslano, mjg59, mitr, j_dulaney) 19:05:54 I suppose I see it as a help, it has certainly gotten a lot of press, and shows that we have a fun side too. 19:05:57 EOF 19:06:31 Most press is good press. I'm not sure it's exactly dignified. . .but. . .oh well, neither am I. 19:06:33 EOF 19:07:47 Honestly, I don't like hot dogs ;-) 19:07:48 eof 19:08:20 I don't see it as FESCo's problem. In a more personal capacity? If we were aiming for corporate adoption then maybe it'd be a problem. But, as our support cycle shows, we're not. I'm proud to be associated with a project that doesn't take itself too seriously. 19:08:24 eof 19:08:38 I doubt anyone really chooses an operating system or a distribution based on a code name. I can't see it making much difference. eof. 19:08:55 The press has been a plus 19:09:28 If Django can get away with a flying pink pony, what's wrong with a Beefy Miracle? 19:10:11 I personally like my hotdogs grilled with some bacon, cheese, lettuce, catsup, pickles, and mayo. I never was a fan of mustard. 19:10:13 EOF 19:11:08 Ok, with the consent of the candidates, we're going to go for about another 20 minutes or so, and get a few more questions in 19:11:21 Q from gholms: As a contributor to Fedora, what do you percieve as the positives/negatives of having Red Hat as a sponsor? (limburgher, mmaslano, mjg59, mitr, j_dulaney, jforbes) 19:15:44 The only real negative is the perception that we're a puppet of a large corporation. I don't feel that this is the case, but I've heard it. The benefits are huge. Infrastructure, people, institutional knowledge, etc, are irreplaceable. I think shoving Fedora outside the walls was the right move, and I think it's great that RH takes our bits and sucks them back in the walls to make RHEL. Fedora is the leading edge generally, and RH sup 19:15:44 ports a stable subset of that. I think it's a marvelous symbiosis, especially since non-RH employees are able to take leadership roles, both formally and informally. RH doesn't dominate, it's a major partner. 19:15:44 EOF. 19:16:57 I see as positive that Red Hat gives Fedora infrastructure, it pays many people to work on Fedora as they dayjob, so they can spend more time on development etc. There are still nonRH Fedora contributors which could take different roles in Fedora development. 19:19:25 As a negative is often seen that RH people are members of different groups like FESCo or that RH people are pushing some not so popular changes into upstreams. 19:20:16 I would say there is more positives, but that should be decided by someone who is not RH employee. 19:20:18 eof 19:20:35 Positives? An incredible amount of engineering work. High-quality infrastructure. And, looking back to the project's beginnings, a great base to build on. 19:20:53 Negatives? The perception that we're controlled by Red Hat. And, in some cases, the perception of some within Red Hat that the project is just there for them to test RHEL changes. 19:21:11 I think the positives massively outweigh the negatives. We're fairly good at pushing back against people who see Fedoraas a playpen, even inside Red Hat. 19:21:14 eof 19:21:24 On the positive side, the quite large amount of work and resources that Red Hat contributes to Fedora; on the negative, volunteer contributors cannot always spend so much time, thus it may be difficult to recognize their effort and dedication when measured against the people working on Fedora full-time, even if the volunteer's effort and dedication is extreme. 19:21:26 I realize people are worried about Red Hat controlling Fedora - but looking at the discussions and voting records of various governing bodies, it should be very clear that Red Hat-employed members at least as often disagree as agree with each other; I have never seen any "block voting". eof 19:21:53 With Redhat as a sponsor, the list of positives is very long. Firstly, we have people who's day job is to contribute to Fedora. Then, Redhat provides infanstructure, funding, ideas, etc. The biggest single negative I can sense is Redhat's lockdown on the desktop team, an issue I see pop up on occaision. 19:21:59 EOF 19:22:01 I don't really see any negatives, I mean there are certain things we cannot do with the backing of a publically traded US company, but community has stepped up in other areas to fill in those gaps. Red Hat throws a lot of resources behind Fedora, both bodies and 19:22:06 infrastructure. I really don't think Fedora would be anywhere near what it is without their support. Red Hat has shown for a long time now that it supports Fedora but will not control it. 19:22:10 EOF 19:23:10 Q from plarsen: How do you think Fedora is different from other major distributions? Do you think we could learn from the other projects and change our model, or do you think Fedora has a better model all in all? (mmaslano, mjg59, mitr, j_dulaney, jforbes, limburgher) 19:25:47 Fedora has faster development, therefore many changes are not completely ready before release. Imho this leads to "too many updates" in stable release. I'm not satisfied with this model, but I don't have any better proposal at the moment. 19:25:54 eof 19:27:03 I think we're rare in being a well-engineered and accessible distribution that still values community involvement. With Ubuntu's move to a more corporate-led development model, it's important that westay there. 19:27:25 When I first got involved in Fedora I had qualms about our ability to produce a user-friendly distribution, and I felt that Ubuntu's model worked better there.I think we've made great progress in that respect. 19:27:39 Where we do lose out is our ability to satisfy users who want a free distribution with longer support cycles. In the past we've been able to point at CentOS - that seems harder now. 19:28:20 But it's impossible to be all things to all people. I don't think anyone's demonstrated an ability to be a fast-moving technology driven distribution while simultaneously supporting enterprise-type support cycles. 19:28:44 Overall, I think our model is solid. 19:28:45 eof 19:28:52 The major differences are exclusive focus on FOSS, willingness to use software that haven't been integrated by other distributions doing the work, and fairly quick time-based releases. 19:28:54 I'm quite impressed by the Debian Policy manual that specifies how packages are supposed to interoperate on various system-wide resources (mail spools, wtmp, ...). We have some similar de-facto standards in Fedora, but they are not codified and the only way to find out about them is to ask the right people. 19:29:07 eof 19:29:38 The model we use is the one that fits best with our philosophy, the four foundations 19:31:11 It isn't perfect, but it is what it is. I see no point in trying to do a long term support version as that would tie up resources even IF we could get people that really wanted to do so. I get the feeling that a lot of Fedora's contributors are here because Fedora has the pace it has. 19:31:12 EOF 19:31:14 I think that there are always things that we can glean from other distributions, but Fedora has a great model in keeping a technical edge, with more focus on usability and QA in recent releases. I would see us making minor changes based on what we see as improvements 19:31:18 rather than wholesale model changes. EOF 19:31:27 I'm generally a fan of the Fedora model. We have a strong commitment to Free Software (having troubleshot both Free and proprietary software, I support this stance. :) ) broad use cases, and technical excellence. I like our release and support cycles, as they allow us to stay leading-edge, and we can fall back on RHEL and derivatives if longer support is needed. I love the concept of rawhide, where we can break and fix things in public 19:31:27 view but without killing regular users' kittens. Usually. :) I'm not aware of any practices I'd like to steal for Fedora, but I'm willing to be educated. 19:31:28 EOF 19:31:57 OK, we're out of time, but I'd like to thank all the candidates once again for their time and willingness to answer questions 19:32:16 Now tell your friends about the upcoming elections, and encourage them to vote! 19:32:21 #endmeeting