Development/SteeringCommittee/Nominations

The nomination period is CLOSED
The nomination period ended at 23:59:59 UTC on November 13, 2012.

VOTE FOR YOUR FAVORITE CANDIDATES.
Fedora contributors can elect FESCo at https://admin.fedoraproject.org/voting/about/fesco-december2012.
DEADLINE: Dec. 9, 23:59:59 UTC

The following elections will take place in November/December 2012:

• Fedora Project Board (two seats)
• FESCo (Engineering) (four seats)
• FAmSCo (Ambassadors) (three seats)
• Fedora 19 Name (separate schedule from the committee elections)

All dates and times noted are UTC time.

FESCo Elections November/December 2012

These members were elected in the last elections:

• Kevin Fenzi (nirik)
• Bill Nottingham (notting)
• Peter Jones (pjones)
• Josh Boyer (jwb)
• Tomáš Mráz (t8m)

As per the FESCo election policy, the following finish their terms, and the seats are up for re-election:

• Miloslav Trmač (mitr)
• Jon Ciesla (limburgher)
• Matthew Garrett (mjg59)
• Marcela Mašláňová (mmaslano)

More information at the FESCo wiki page.

For the last election, see NominationsMayJune2012

Eligible Voters
Voting eligibility is determined by a community member's Fedora Account System (FAS) memberships.

To vote for FESCo you must have cla_done + one other "non-cla" group in FAS.

Candidate template

Introductions

• Mission Statement:
• Past work summary:
• Future plans:

Questionnaire

CLOSED
The answering period is now closed (after November 18 2359 UTC). Received responses are below:

• What skills do you bring for FESCo?
• Where do you see Fedora in the next year?
• Where do you see the Fedora Project in five years?
• What is your priority for Fedora?
• What are your thoughts on the Feature process?
• What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

Candidates

Stephen Gallagher (sgallagh)

Introduction

• Mission Statement:
  • Make Fedora THE platform for rapidly developing the next generation of free, open-source software.

• Past work summary:
  • Red Hat employee since 2008, developed the System Security Services Daemon, participant in the FreeIPA project. Currently advising the OpenLMI project and working on packaging Node.JS and its dependencies. Fedora Hosted admin maintaining ReviewBoard. Working with the OpenShift developers to host tools for use with Fedora such as Gerrit. Former FESCo member from June 2011 - 2012. Currently employed as the BaseOS Architect at Red Hat.

• Future plans:
  • Continue to drive Fedora to become the best platform for developing exciting new technologies for the desktop and datacenter.

Questionnaire

• What skills do you bring for FESCo?

I am currently employed as the BaseOS architect for Red Hat. My full-time job at this time is to facilitate collaboration between different open-source projects and help them avoid duplication of effort as well as resolving disputes between projects with competing technologies or goals.

• Where do you see Fedora in the next year?

In the next year, I anticipate that we're going to see a significant shift in Fedora. The technology ecosystem is shifting from its classic development model of reinvent-the-wheel compiled languages into the more dynamic world of web applications built atop dynamic infrastructures such as Django or Node.JS. Fedora has always represented the "will of the people" and will be adapting to these new development styles.

• Where do you see the Fedora Project in five years?

I see Fedora refocusing on its core strengths over the next five years. We've spent a long time being everything for everyone, and it's become clear over the last several months of devel@ mailing list discussions that this isn't working for us and is not sustainable. My view of the five-year future is that Fedora is going to simplify its plans and shift back towards being a platform distribution as opposed to a software distribution.

• What is your priority for Fedora?

I have two primary goals in mind for Fedora:

1. I want Fedora to be the distribution that software developers are *excited* to use for the development of the Next Big Thing.
2. I want Fedora to provide a powerful and extensible platform for doing that development.

• What are your thoughts on the Feature process?

The Feature process is too bureaucratic in some instances while being simultaneously toothless in other situations. For example, there are many Features that come in that are simply rubber-stamped into the distribution because they were raised as Features simply to be added to the Release Notes and Talking Points. I think we should have a separate process for these additions that should be handled by FAmSCo instead, since this is more an evangelizing task. The purpose of Features should be constricted to dealing with those changes that have impact throughout the Fedora Project; it should address those tasks that require coordination among multiple projects or those whose slippage could delay releases.

Additionally, there are Features that are approved without a sufficient understanding (or communication) of the risks involved. Features such as the recent Anaconda mass changes that have significant likelihood of slipping the release should be communicated out to the community very carefully ahead of time. Such enormous changes should be communicated throughout the community and effort made to involve the whole community *early on* to do what they can to facilitate the Feature so that we minimize the risks of slippage.

• What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

In my role as a facilitator, my efforts will carry more weight if I am part of a team whose job it is to enable the creation of a unified product. I can negotiate between teams with the additional influence that a position on FESCo can provide.

Jon Ciesla (limb)

Introduction

• Mission Statement: To further the goals of the project and Free Software in general by helping enable contributors to bring the highest quality and most diverse collection of software to the distribution. I'm fully committed to the goals of Free Software, for ideological, but also primarily technical reasons.
• Past work summary: I've been a Fedora user since RHL 7.1, and an active packager since 2007, as well as a sponsor and member of FESCO and the FPC. I initially focused on games and php applications, but have expanded to other things over time. I also encounter and deal with many of the issues we encounter as a project in the course of my day job.
• Future plans: Ideally, I'd like to find ways to encourage and educate new contributors. I've sponsored a few new packagers, but would like to help shorten the time from first interest to active packager, and can only do so much on my own. I also have ideas and opinions on many areas FESCO addresses, including the Feature process, and would like to continue to contribute what experience I have to those conversations. I'm also very much interested in helping ARM achieve Primary architecture status, and have been doing a bit of work towards that goal.

Questionnaire

• What skills do you bring for FESCo?

Many years of Linux use and administration experience, several years experience as a Fedora packager and developer, and both work and Fedora leadership experience.

• Where do you see Fedora in the next year?

I think we'll see ARM become a primary architecture, and continue to advance the progress of free software with the latest and best software. We'll work out the kinks in our feature process, and grow the community.

• Where do you see the Fedora Project in five years?

We'll be a technical, if not numerical, leader on the desktop, in the server room, on mobile, in the cloud, and making serious inroads in at least one place that doesn't exist today.

• What is your priority for Fedora?

My day-to-day priorities are fixing FTBFS bugs and updating versions on software important to me. Most of my energy outside of my direct packages has been on ARM FTBFS and SCM maintenance.

• What are your thoughts on the Feature process?

There needs to be a closer relationship between FESCO and feature owners, and the feature submission process needs to begin and end sooner in the cycle. Ideally, I'd like to see each feature assigned to a FESCO member whose responsibility is to act as a patron, or sub-feature-wrangler for that feature, making sure the status page matches reality, that the feature is progressing, and assisting if needed.

• What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

Being a part of FESCO, in my view, gives me greater insight into the technical direction of the Fedora project as a whole, and I'd like to continue that, particularly with regard to me ideas around the feature process.

Matthew Garrett (mjg59)

Introduction

• Mission Statement: To help Fedora developers get their work done in such a way that we ship a distribution that benefits our users.
• Past work summary: I'm a former Red Hat employee keen on continuing to contribute to Fedora. I've worked on various power management and ACPI features, and have been leading the Secure Boot implementation that's been adopted by most significant Linux distributions. I've recently been spending time on helping with the remaining Anaconda and upgrade issues for Fedora 18.
• Future plans: FESCo exists to enable Fedora contributors to get their work done, providing that that work doesn't adversely affect other contributions or the goals of the distribution. That isn't how it's always been treated recently. I want to focus on returning FESCo to being an enabling group, while simultaneously engaging the community in discussions to fix the various infrastructural and policy flaws that stand in the way of developers.

Questionnaire

• What skills do you bring for FESCo?

I'm an experienced developer with detailed knowledge of how most system components fit together. I've worked on the kernel, and I've worked on desktop applications. I've worked on pretty much everything in between, too. I've also been involved in the development of other distributions, so I don't approach issues with the inherent assumption that the existing Fedora solution is necessarily the best.

• Where do you see Fedora in the next year?

With luck, back to regular release cycles that can benefit from the infrastructural work that's been carried out this cycle. I don't imagine that there'll be massive changes. ARM may have reached the point of being a primary architecture.

• Where do you see the Fedora Project in five years?

Where I'd *like* to see the project in five years is a place where people spend more time developing and less time arguing, but that might be a fundamental outcome of our community model. There'll probably be even more focus on cloud than there is now, and I expect that ARM will have been a primary architecture for a significant period of time. I'd hope for less infrastructural churn in the lower levels of the distribution - we'll have rewritten everything enough by then that we should finally have got it right.

• What is your priority for Fedora?

Pragmatic technical excellence.

• What are your thoughts on the Feature process?

It's currently mostly pointless. There's no way to mandate that development goes through the feature process, and most of what does is doing so purely so a box can be ticked somewhere. Our failures to communicate development aren't helped by getting people to fill out forms.

• What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

Vote in FESCo decisions. If you trust my judgement, elect me. If you don't, don't.

Miloslav Trmač (mitr)

Introduction

• Mission Statement: Make Fedora work better for its primary purpose as a distribution - to turn various differing upstreams into a consistent and well-integrated whole.
• Past work summary: Contributor since RHL times, worked on many things including a tcsh internals rewrite, initscripts, pyrpm, switch from MD5 to SHA-256 hashes in RPM and other places, audit work from the kernel to GUI layers, volume_key, encrypted disk support in libvirt, kernel's crypto interface, and the Fedora signing server. Used to be a heavy-duty translator into Czech.
• Future plans: Fedora is often the place where packages affected by changes other packages first interact, and handling this well is critical for fulfilling the above-mentioned primary purpose of a distribution. To that end, I plan to work on improving the Feature process, and otherwise improving the handling of changes that affect other packages and ensuring distribution-wide consistency - while making it possible to make successful transitions faster, not slowing change down in bureaucracy. I also generally favor policies that allow quick bug->fix turnaround time and allow more enhancements into released versions of Fedora. Outside of FESCo my interest is in improving security of Fedora.

Questionnaire

• What skills do you bring for FESCo?

From the technical point of view, probably an above-average understanding of most of the major functional areas of the distribution: For example, I've been doing kernel programming, GUI programming, web programming, I've worked on the old init/network scripts. This was directly relevant to FESCo - looking at the FESCo tickets, I think I've been one of the more active people in researching the technical status/issues/interactions of various proposals.

From the organizational point of view, I've been on FESCo for the past year, and thus have some understanding of what the pain points are and what the possible solutions might be - certainly more than I had when I started in FESCo.

• Where do you see Fedora in the next year?

I want to help with, and have some proposals for:

• • More cooperation between maintainers of various packages, resulting in more complete and less painful integration of new features.
  • Improved processes that "scale" with the task, getting out of the way for simple cases and handling the larger cases better. (See the "Feature process" question for some details.)

I also want to start moving Fedora toward:

• • Better QA (more automated testing, more involvement of testers in planning of updates and feature integration); in my experience doing such work upfront pays off in the future, especially when a component is faced with a large magnitude of "external" changes, like it is often the case within Fedora.
  • More agreement on who the primary users and expected uses are, to establish a better common ground for the more controversial technical discussions and decisions that are often primarily disagreements about the users/uses. I don't think these things can happen within a year, but we can make some progress.

• Where do you see the Fedora Project in five years?

The basics should not change: integrating upstream open-source software into a distribution in a collaborative way, quickly adopting new technologies.

We should get better at it, though - integrating the new things quicker, better and more completely, with fewer surprises and less unexpected breakage.

Currently a better feature process, and better QA seem to offer the most effective ways to improve. The better QA will take some time to develop, and we will certainly encounter and have to overcome other, currently unexpected, hurdles towards the goal.

• What is your priority for Fedora?

Short-term it is clearly improving the "feature process"/communication mechanisms (see the "five years" question for rationale).

• What are your thoughts on the Feature process?

It mostly works well as a marketing device. For technical coordination, there's certainly room for improvement

As a possible immediate improvement, Marcela Mašláňová, Tomáš Mráz, Jaroslav Řezník and me have prepared a specific proposal that will:

• • significantly improve feature visibility, which alone should make coordination easier and avoid some surprises
  • simplify the process for changes that don't need FESCo micromanagement
  • get FESCo more involvement in the integration and quality of more risky features.

Over time, I would like Fedora to move towards somewhat higher expectations from package maintainers, at least for the most important packages (at least packages shipped in the default spin, or perhaps in any spin?):

• • Setting up "release goals" for each Fedora release, where every maintainer is expected to update their own package for some change.

The problematic sysv->systemd conversion is a current example. We can expect similar migration necessary for GTK+ 2->3, Python 2->3 in a not-too-far future.

Ability to distribute such work across all package maintainers - and to really get it done for the next release - is critical to Fedora's ability to quickly integrate new technologies.

• • Puting more focus on the already existing package maintainer responsibilities (dealing with bugs, notify others about changes) - perhaps making it easier to become a comaintainer of "problematic" packages.

• What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

Many contributors express opinions on policies, processes and distribution-wide technical decisions decided by FESCo. All of them are heard, but ultimately they are effective through a representative on FESCo, and I'd like to serve as a representative for people who agree with my mission statement and plans.

Toshio Kuratomi (abadger1999)

Introduction

• Mission Statement: To refine existing FESCo procedures in light of problems we've encountered.
• Past work summary: I've contributed to Fedora since the fedora.us days and was a member of FESCo during the merge of Core and Extras. Recently I've been an active member of the Fedora Infrastructure Team working on FAS, PackageDB, and general scripting and bugfixing, worked on Packaging Guidelines as a member of the Fedora Packaging Committee, and have just returned from a stint on the Board. Around alpha release, I can often be seen to step in to get python packages building or work on bugs that have hit the community's radar but aren't important enough to hit a blocker list.
• Future plans: Past FESCo's have streamlined many policies including the updates policy, a fast track for nonresponsive maintainers, and how FPC guidelines are approved. The current and next FESCo are likely going to be tackling an update of the Feature Process. There's been a lot of work around this already. Many packagers have contributed to the Fixing_features wiki page. FESCo has been discussing issues on the Refining Features ticket. I'd like to help organize the identified problems and suggested solutions and incrementally improve pieces of the policy. If we finish that work, it may be time to take another look at improving the non-responsive maintainer policy.

Questionnaire

• What skills do you bring for FESCo?

• • Experience working in groups that are striving to reach consensus (FPC, Fedora Board)
  • Large amount of experience with packaging for Fedora. I've been around since the fedora.us days and served on the Fedora Packaging Committee since its inception.
  • Good python programmer, okay shell scripter, rusty C programmer, for those times when FESCo will need to provide manpower to work on blocker bugs.

• Where do you see Fedora in the next year?

There will be incremental changes in the next year. But we'll have started talking about some new, far reaching changes to how we create the distribution. We'll be tossing around ideas like every other release being more like an update release with minimal changes to the core platform and what level of support we want to offer to people creating copr addon repositories for Fedora.

• Where do you see the Fedora Project in five years?

There will have been a few major changes to Fedora by the time we get five years down the road. We have accumulated a lot of processes that aren't working very well (and contrariwise, a lot of things that are working well). I think that similar to no-frozen-rawide, the core and extras merge, and Fedora Core 1, we're closing in on a place of re-evaluation where we're ready to make some changes to how we produce the distribution. I think those changes are going to be evolutionary rather than revolutionary but they aren't going to be small either. The changes that will inevitably come to the Feature Process in the next year are just the first of several of these large changes that we will see.

Although it's hard to spot things that are barely on the radar, I think that once the Copr buildservers become available in the next couple years we'll go through several phases of integrating what they offer into our universe of offerings. I would hope that we could get to the place where we offer people who care to work on the side repos some measure of support for providing some sort of full-service to the people who use them. Issue trackers, hosting for them. An automatic way to install repositories, perhaps some way to hook into the Fedora release schedule. However, watching the various secondary arch efforts, I'm not sure that this is where the project will go and if it does, whether it will be able to go there in the next 5 years.

• What is your priority for Fedora?

Changing the Feature Process. Working on the AWOL maintainers process. Attempting to change the culture of package ownership to be more open to letting people work on things that they are not the owner of.

• What are your thoughts on the Feature process?

It was a good first try but it's in need of some revisions. Some of the things that we have been kicking around for a while that I don't think are very controversial to implemment:

• • Make the feature process easier for things that just need documentation and more structured for things that need coordination by making separate processes and templates for each.
  • Give more power to the Feature Wrangler to approve things that fall into the documentation only set.
    • Probably want to get more people to do Feature Wrangling so that approvals at this level don't become a single-point-of-failure
    • Write some guidance about how to tell the difference between a feature that is docs only and a feature that needs coordination.

Those changes will help keep fesco free to deal with and focus on things that may be a problem within a release cycle instead of spreading themselves out looking at many things that merely require an entry in the Release notes if they get done. They'll also clear up some longstanding confusion and maintainer issues where various parts of the feature process don't map well to the particular type of feature that's proposed (Release notes for upgrading the boost library, for instance; the current alpha freeze schedule for leaf packages like the gimp or inkscape).

I think that people are currently mainly interested in the Feature process because of F19's slippage and unfortunately solutions to that seem to be more controversial or less fully fleshed out. Some of the problems leading to slippage:

• • We let many things go through even though they aren't ready at the milestones that are on the schedule.
  • We have a theoretical model for people to develop features over muliple releases and only release them into Fedora when they're ready. However, some teams claim they don't have the manpower for this.
  • We have a theoretical model where people should start developing for the next version of Fedora once rawhide branches. But only some people work on this schedule.

There are some ideas on fixing these but they all cause somebody pain. We could tell more people to revert their features if they aren't ready in time. We could tell certain critical components that they aren't allowed to push things into Fedora until they're already finished -- or if they go in, they very strictly have to be finished by alpha (or a new milestone before that) otherwise, the team must spend the rest of the cycle reverting their changes and stabilizing for that. We can enforce people doing more work on the branched release by freezing earlier and staying frozen. Then QA and releng would control who was doing work on branched... everyone else wouldn't have the ability to push things to branched so they'd have to work on rawhide.

I don't think we're quite ready to swallow the tradeoffs that go with any of these so a lot more work needs to happen to find something that will be palatable to everyone.

• What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

Hopefully very little :-) Proposing changes to existing policies (which I hope is the most iportant thing I'll be doing) can be done by regular contributors as well as members of FESCo.

Being a member of FESCo *will* give me the opportunity to vote on Features which I can't do as a regular contributor. However, I am definitely *not* promising to do that job differently than any other member of FESCo currently does. I may ask more questions than the average member of FESCo does but I won't try to filibuster votes with endless questions. I will try to get proposed features modified to seek consensus, but I won't block things if there's nothing further that can be done to make something satisfy more people.

From a few of the controversial votes in the past few releases, I think I would have voted against several of them (UsrMove, for instance) but voted for others (for instance, SecureBoot). Given the information FESCo was given on the current hot button topic, anaconda's NewUI, I think I would have voted to approve that as well.

So do not vote for me if you think my voting record on features would have significantly changed what features made it into new versions of Fedora. I'd just be another member of the group charged with making hard decisions that affect the entire project.

Marcela Mašláňová (mmaslano)

Introduction

• Mission Statement: Fedora should be opened for new projects, but we need to work more on inclusion of changes. Features or changes of default shouldn't lead to breakage of rest of the system.
• Past work summary: Red Hat employee since 2006. I started as a maintainer of small utilities in Base group and become a Perl maintainer. Currently, I'm working as a supervisor of Languages group. I have almost finished second term in FESCo. My current project is Software Collections, which are able to provide more versions of the same software in a single distribution release.
• Future plans: Fedora should provide environment stable enough for development of new features. I'd like to work in FESCo on review of new features and help to communicate between group of developers so the lack of communication does not bring surprises late in the development cycle of release.

Questionnaire

• What skills do you bring for FESCo?

I was a Perl maintainer few years, therefore I know a lot about maintenance of projects with huge number of packages in Fedora. I'm aware of problems in our infrastructure during rebuilds. I'm mainly working on interpreted languages.

• Where do you see Fedora in the next year?

I hope we will be working on stabilization of our distro. The last few releases brought huge changes and many of them weren't finished. I'd like to see more work on bugfixing than new features at least for one release. After release or two we could have a much better distro, but that depends on future features and how they will be done.

• Where do you see the Fedora Project in five years?

Sounds like HR question, but okay. I'm afraid there is a possibility that Fedora would break up into smaller communities around different projects. Part of developers and their requests have been ignored (Server, Virtualization, ..). It might happen that Fedora will lose many users if we don't start talking with all projects working within Fedora project. I don't think we should focus on the desktop anymore. The market had changed, for pure desktop usage tablets, macs, or even smartphones are sufficient. Let's provide a strong development distribution, which means cooperate much better in distribution and focus on inclusion of new projects to work well within Fedora.

• What is your priority for Fedora?

He? If you meant which use-case is a must for Fedora, then Platform for development - easy to pick what you want without many useless dependencies.

• What are your thoughts on the Feature process?

We already created draft of improved feature process. We'd like to start discussion about it very soon. Our draft of Feature process is here

• What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

As a FESCo member I can decide, which features will be accepted and which won't.

Martin Sivák (msivak)

Introduction

• Mission Statement: Make sure the distribution stays modular and adaptable to the needs of many different user groups
• Past work summary: I have been a linux user since 1999, starting with Red Hat 7.1 and moving through different distributions including Linux From Scratch to the current Fedora 17. I also co-started a local annual linux conference for beginners and intermediate users in 2006 and have led the organization team for the last 5 years. Since 2007 I have also worked for Red Hat in Brno, mostly focusing on the anaconda internals, text mode and driver loading subsystems.
• Future plans: We have some places in the distribution which affect very large number of other packages and environments. Some of those were even adopted by other distributions and people are working on making the learning curve for converts smooth. Unfortunately, sometimes we forget the motto of one tool doing one thing, but doing it properly. When that happens, we loose the ability to replace packages easily, integrate them in different environments and also to test them in isolation. But all those points are important from the engineering and QA point of view and make it easier for other desktop environments and distributions to integrate the tools. So I would like to help tweak the Feature process to take this into account and work with the community to make sure Fedora parts are more easily reusable by others.

Questionnaire

• What skills do you bring for FESCo?

As I already posted in my nomintion, I have led a team which prepares a conference for about 500 attendees for five years. That probably means I have some negotiation and planning skills. As part of the Anaconda team I am also used to explaining ideas and goals to people who do not like those. And that takes diplomacy and self control.

Other that that, I have the usual set of engineering expertise starting with masters in IT and ending with the relevant work experience. Having (co)maintained couple of packages myself I think I understand the contributors point of view as well.

• Where do you see Fedora in the next year?

It should have better definitions of its goals and better mechanisms for dealing with unforeseen issues and delays.

We cannot afford weeks of improvised slipage. We can slip if that is needed, but it should be planned and consistent with the goals, not based on improvised decisions.

• Where do you see the Fedora Project in five years?

Still state of the art, but less chaotic for the end users and contributors.

• What is your priority for Fedora?

Making sure Fedora has a clear goal maintainers can use to decide about features and keeping the distribution modular so it is possible to replace any component easily if it is needed.

• What are your thoughts on the Feature process?

I would like to see three things:

One is a document specifying what should Fedora look like and who it is for. We can than use it to implement default distribution behaviour on top of the upstream packages (APIs, btrfs vs. LVM vs. plain partitioning, /home partition, config files, graphic themes and so on) to avoid late in the release discussions about whether the default behaviour is right or not. Changes to this policy might then be regarded as Features and voted upon.

Secondly, the features are currently used mostly as topics we want to advertise. We do not always have the manpower to maintain the old version, once the upstream project decides to abandon it. And because most of our package maintainers and contributors are volutneers, we cannot force them. That means we are limited in what we can possibly do. Diplomacy is one possibility. Making sure the packages are smaller, better contained and thus testable and replaceable/revertable is another.

And the last one is technical: When a feature gets filled we could find all packages that directly (and indirectly?) depend on the package the feature is filled against and notify the maintainers. The devel list is sometimes really busy and whole threads tend to get lost in history fast.

So I believe that simply updating the Feature process won't solve the situation. It has to be a combination of changes to different policies. And for some situations, there just isn't any golden rule that solves everything.

• What will you be able to accomplish if elected, that you couldn't as an unelected contributor?

I will be able to directly influence the policy changes that would lead to smoother release cycle and better experience for contributors. By helping making sure the distribution stays modular I would be also able to help spins efforts and spreading Fedora based tools across the linux universe.