Comment by notacoward | Hacker News Reader

Comment by notacoward | Hacker News Reader

Parent Full thread

I think the Fedora philosophy/positioning is pretty well summarized right there on the project page.

> Freedom. Friends. Features. First.

Fedora is a cutting-edge distribution, but a Linux distribution is too large a thing to have only one cutting edge. Sure, if you want the latest applications and higher level libraries/frameworks, you might find them in another distribution first. On the other hand, if you want the latest core/infrastructure bits - e.g. system daemons, compilers, hypervisors - you'll probably find them in Fedora first because that's the distribution in which those kinds of developers do most of their work. Those other "cutting edge" distributions you mention might not have to wait for an actual release, but they still have to wait for the patch from the original developers plus the repackaging into their own native formats and repositories. "Cutting edge" is contextual. It all depends on what you're doing.

Disclaimer: I'm a Red Hat employee and some-time Fedora contributor. But at least I'm not being gratuitously negative about others' work.

If I'm not mistaken, that's because Red Hat funds a lot of work in those areas. Even where it doesn't fund it, those are the really interesting bits for a server/enterprise OS, and that's what Fedora is a feeder for, so they get a lot of attention.

Our policy at Red Hat is upstream first. Work is being done upstream and benefiting Arch and everyone else. It's not on Fedora. Fedora just benefits from an extremely good QE cycle compared to other distros, and a well-integrated set of packages, which is something rolling-release distros don't offer, not that there's anything wrong with that.

RH development is a feeder for Linux. A lot of RH employee contributions upstream are in the categories that are talked about, but so's a ton of work on GNOME and other areas.

Fedora packageset stabilization is a feeder for RHEL (every few years Fedora settles down a bit as it gets ready for a branch, then screams off again), but the code itself feeds everyone.

I didn't mean to imply that changes were going directly into Fedora and not upstream, just that it both shows where the emphasis is, and it's likely to result in a disproportionate amount of time spent making sure those changes are both quickly available and very tested and stable (you want to see a return on your investment ASAP).

We make our money on support.

A nontrivial amount of bugs fixed upstream are found and reported against in-support versions of RHEL. But in a broader sense, there's no "immediate return on investment" pressure here.

We work with upstream communities. So there are upstream planning meetings which set feature development, which anyone is free to participate in, or we directly participate in apache/openssl/gnome/openstack/whatever meetings. New features are set and developed by the upstream product, where we (as developers) spend a lot of our time. We're not doing it in-house and pushing it back.

We try to make sure they're tested and stable through CI and QE testing (foo-1.2.3.noarch gets marked as the version in which bug #1234 is fixed in -- QE tests and verifies this before release).

There's some emphasis there because Satellite, Openstack, RHEV, and other "server" product entitlements and support are our revenue stream, but there's a significant desktop team, and kernel team, etc. We as a company are much less focused on what makes money and more interested in "what's the best tool for this job" and "how can we push Linux forward".

To that end, there's a heavy lean towards GTK/GNOME solutions over QT, but that's more culture than corporate direction. And there's a "disproportionate" amount of effort towards server products because that's what people use Linux for and that's what we work on, but the community drives our priorities, not the other way around. We're a relatively small company (for our revenue), and people work in one area. If I'm working on Openstack (upstream and downstream), pretty much all my effort is going there and none is going towards Firefox (or whatever). But being on a product team/niche isn't any different at Red Hat than anywhere else.

I didn't mean to make it sound like a business strategy (entirely), I mean it more as a natural progression of how people function. If as an engineer you are spending a lot of time working on Openstack, I'm sure you want to see the new advances and features in the product that you've invested so much time and effort into get into the distro ASAP, as long as they are stable (egg on your face is much worse than delays). I just view that as a facet of human nature, and one that has worked for Red Hat's advantage (whether on purpose or serendipitously) quite well.

> I didn't mean to make it sound like a business strategy (entirely), I mean it more as a natural progression of how people function. If as an engineer you are spending a lot of time working on Openstack, I'm sure you want to see the new advances and features in the product that you've invested so much time and effort into get into the distro ASAP, as long as they are stable

That's not really up to us, though. We still have product managers and project managers and project leaders who decide that Feature XYZ is going into Openstack Zeta, which comes back around to the original issue.

If I'm an engineer spending a lot of time working on Openstack, it's likely that I'm spending all of my time (other than hobby projects and side projects) on Openstack, just like you may be spending it on whatever your mainline product is (if you're a dev).

All devs probably want to see their features hit stable as soon as possible with wide consumption, but Openstack is a good analogue to Fedora, in the sense that things are operating on a schedule. We aren't releasing new versions of Nova/Neutron/whatever whenever we want or whenever we think it's stable or cool. We try to orchestrate that.

Fedora tries to orchestrate projects.

Absolutely, that is a big part of the reason. For anyone who ever has to work on RHEL systems, Fedora offers the most comfortable familiarity. Context-switching between multiple distributions' ways of doing things (especially packaging) is a pain. Some do it anyway. My little micro-server upstairs is running Ubuntu right now, because that was easier to get running than the equivalent Fedora ARM bits when I bought it. It has largely supplanted my desktop system which is running Arch. OTOH, this laptop is running Fedora, and when I set up a new server in the cloud for some testing, I'll generally go for Fedora or CentOS out of habit. That's just the default for a lot of systems-focused people, whether they work at Red Hat or not.

Reply on news.ycombinator.com