I was just voting on FLOCK talks and happened upon this talk proposal:
What does Red Hat Want?
It’s no secret that many Fedora participants work for Red Hat. Or that Red Hat provides funding for the Fedora Infrastructure. There have been many conspiracy theories over the years centering on what, exactly, does Red Hat want out of Fedora in return. This talk, by the Red Hat VP who runs the RHEL engineering team, proposes to address that eternal question. What does Red Hat want? Join Denise Dumas to learn what Red Hat is working on next and how we would like to work with the Fedora community
In my time working for Red Hat on Fedora I often found that the Fedora Community was operating in a vacuum. We wanted to run a Linux Distribution that we had a stake in and a chance to modify to our needs. We also knew that Red Hat invested a considerable amount of money into Fedora to support our being able to do that. But what we were in the dark about was what Red Hat expected to get out of this partnership and what they wanted us to do to justify their continued investment. Although over time we did get our hands dirty maintaining more of the packages that made up the distribution, in a lot of ways we never graduated beyond mricon’s 2004 tongue-in-cheek posting about Red Hat’s relationship to its community (and its own internal divisions at the time).
In the last few years, Red Hat’s portfolio of products and future directions have greatly expanded. No longer just a producer of a Linux distribution, Red Hat is pursuing revenue sources in application middleware, both IaaS and PaaS pieces of the cloud, and containers. They also have engineers working on a multitude of open source solutions that enhance these basic products, adding flesh to the framework they set up. But where does the Fedora Community fit into this expanded roster of technologies? The Fedora Product has been very focused on “A Linux Distro” for a number of years but the Fedora Community is very broad and multi-talented. I’m hoping that Denise’s talk will provide an entrypoint for Fedora Contributors to start talking about what new directions they can take the Project in that would align with Red Hat’s needs. There’s a number of difficulties to work out (for instance, how does Fedora keep its identity while at the same time doing more work on these things that have traditionally been “Upstream Projects”) but we can’t even begin to solve those problems until we understand where our partner in this endeavour wants to go.
This is something I’ve been noticing for a while and am finally getting around to blogging.
In the first days of FESCo, Thorsten Leemhuis was the chairman. One of the quirks of his time was that we’d encounter a topic where we voted on a solution and found that a majority agreed with one sentiment but it wasn’t unanimous. When that happened, Thorsten would be sure to ask if there was anything we could do to make the solution more acceptable to the dissenters even if they still wouldn’t vote for the proposal.
This sometimes lead to discussions of a proposal that had been approved with margins like 7 to 2 and after the discussion and changes, the vote was still 7 to 2. So from an external standpoint, this might be seen as unproductive. Why don’t we just get a decision made and move on?
But over the years I’ve watched a lot of other split decisions be made on several committees from both the inside and the outside and it’s struck me that, perhaps, we don’t do nearly enough of this sort of examination. Making changes after it was clear that a majority agreed with the basic proposal had several beneficial effects:
- It made the proposals more palatable to more people by getting rid of at least some issues that had made their way in to the final drafts.
- It forced dissenters to figure out what specific things they wanted to be changed in the proposal rather than simply being able to say “I hate this whole thing”.
- It made more people a part of the decision– whether or not they voted for it, if some of their ideas were in it, they felt some ownership for having help craft it.
- And perhaps most importantly, it let everyone know that the door of communication still worked. People found that their ideas were still valued by the other members even if they didn’t agree with each other on the overall picture.
So what can we do with this? Maybe it’s too much to ask that we look over every little decision we make where there’s disagreement and attempt to find every last bit of common ground that we can (There were certainly times when it seemed to take forever to make a decision) but what about decisions that are close votes? What about decisions that have days-long threads as part of their backstory? In these cases, consider the proposal that the majority agrees on to be a strawman. A starting point from which to start chipping away to see what changes can be made that are still acceptable to the majority while addressing many of the issues that the minority has. Remember that the goal is to craft a compromise that addresses as many concerns as possible.
Are you on IRC? Are you at FUDCon? Do you have a project that you want to happen in Fedora?
The Fedora Board is working on choosing goals that each individual member wants to champion and bring to fruition this year in Fedora. So if you have some idea that you think a Board member’s help will make work better, grab your nearest Board member[*] and ask them to bring it up on their Sunday meeting. One of them may take it up as something they think they can work on and help accomplish in the coming year.
[*] Board members you may see wandering around at FUDCon:
- Jared Smith
- Toshio Kuratomi
- David Nalley
- Peter Robinson
- Jon Stanley
- Christoph Wickert
The past few weeks I’ve been coordinating a new release of the Fedora Account System(FAS). Since FAS is something used within Fedora but not a whole lot of other places, development is usually driven by a relatively small handful of people: Ricky Zhou, Mike Mcgrath, and I. This release saw a large number of other contributors which has been very good as the three of us have been increasingly pulled into other projects so our time for FAS has steadily decreased.
- Adam M. Dutko fixed several long standing bugs and feature requests
- Luis Bazán updated several pieces of the UI
- Sijis Aviles switched us from signing the CLA to the new FPCA
- Pierre-Yves Chibon created a new captcha to replace the universally hated one that we were employing
- Jun Chen added a means to clear a user’s ssh key
- Nick Bebout started the work of removing copyright phrase-ology that we no longer want to use (“All rights reserved”) and tracking down which people needed to agree that we could switch licenses from GPLv2-only to GPLv2-or-later
- Jim Lieb contributed code to make handling of languages easier and made FAS more configurable for use in other sites.
- and for the first time in several releases we coordinated our release with the Fedora Translation Team on transifex so that the translations they contributed could go out with the first release instead of when a subsequent bugfix was released.
So let’s take a brief tour of some of these new features.
Although we’ve been using transifex to manage translations for FAS for a while now, I hadn’t really understood how to leverage the full power of the Fedora Translation Team to get translations. Thanks to some prodding by pingou, I got in touch with the translation team this time around and arranged for a string freeze before release during which they worked hard to translate FAS into their native languages. Thanks to transifex, I can show you this nice graph of their hard work:
Top translations: fas » faspot Full graph of translation stats
Clearing SSH Keys
When Fedora Infrastructure recently made the decision to invalidate public ssh keys because we had no way to tell which users might have hosted their ssh private keys on other projects servers which had been attacked and infiltrated, one of the options was for a user who didn’t actually need to use ssh to simply remove their ssh. Unfortunately, the web interface didn’t include the ability to do that so user’s who wanted to go this route had to contact one of the admins and have them remove it for them manually. Thanks to Jun Chen, users can now perform this step for themselves:
There have always been many times more accounts in FAS than there were active contributors to Fedora. In itself, this wasn’t a problem. However, at some point, spammers started signing their bots up for Fedora accounts as they found that with that, they could write to the Fedora Wiki. To combat this, we added a captcha to the signup process. However, we quickly found that the captcha we added was too hard. Many people came to us to complain that they could not answer the captcha successfully. Thanks to pingou, we have a new captcha which displays a simple math equation in a much less distorted image. Writing the correct answer to the equation is all you need to do.
These are just some of the more user visible changes. If you’re interested in the more behind the scenes changes (SELinux fixes from ricky, password strength checking, and more), check out the changes in FAS’s git repository.
It struck me on several levels. It was told by an excellent straight man
. It had a great story. It was gently deprecating. In short it was very entertaining.
But beyond that, it also highlighted one of the core philosophies of open source that sometimes gets lost in mailing list threads about user base and popularity. Open source is powered by people wanting to scratch their own itches. Having a popular product is fun but people will work on something that only has a small amount of users as long as it is a good base for them to do what they want.
Here’s a positive email conversation to send you whistling about your day:
Last week, a few people crawled out of the wordwork and decided we wanted to start porting third party python modules to python3. We need a bit of structure for this since some of the time, we have people who are packagers for individual Linux distributions (or even, just at the one company that they work for) doing the job of porting something they need over. The work that is done in that one place then doesn’t get upstreamed for some reason (upstream is dead, upstream only wants to work on python2 problems at the moment, you got busy and forgot about it). Having a central place to coordinate these efforts would make for a nice way to make sure that we’re working on things that no one else has done instead of everybody duplicating efforts.
With that in mind, we’ve decided that we should collaborate on the python porting mailing list to try to organize what we’re doing. If you’re interested in doing some of this python3 porting work, join up and see how you can help!