Fedora Holds Summit To Map Its Future

lisah writes "Last month members of the Fedora community met for a three-day summit (wiki here) designed to chart a course for future version releases as well as to plan other Fedora projects. Team members say they want to leverage the enthusiasm of a community that has demonstrated a willingness to develop Fedora Extras (add-on features to the Core package) and support Fedora Legacy (past releases). Red Hat's community development manager, Greg DeKoenigsberg, said, 'Community contributors have proven conclusively over the past 18 months that they can build packages every bit as well as Red Hat engineers — better, in some cases.' In addition to creating several proposals that will be introduced the the community for input and feedback, the summit also gave rise to the newly-created position of Fedora Infrastructure Leader." Linux.com and Slashdot are both owned by OSTG.

Comments

Fedora is important

[slapys]

Fedora was the first Linux operating system I ever used. This applies to the majority of my Linux-using friends as well. Perhaps this is because people already know the name of Red Hat, and discover Fedora as a result. In any case, the quality of Fedora is significant because it determines the first impression of Linux on many people. Even though I have switched distributions, it it possible that I may have stopped using Linux if I had come to the conclusion that Fedora was of too poor quality to use on a daily basis.

Re:Fedora is important

[qortra]

This applies to the majority of my Linux-using friends as well. Perhaps this is because people already know the name of Red Hat

I think this was definitely the norm about 3 years ago when it was created. Certainly, before that, Red Hat had incredible name recognition, and as it result, most new Linux users tended to get Red Hat (sometimes even get retail copies at the time).

However, I would claim that Ubuntu has now usurped Red Hat's (and Fedora's) position as the most recognized distribution among Linux newbies. Certainly Distro Watch agrees with me. Not that DW is conclusive evidence, but it tends to be a good indicator.

I do agree with you though; Fedora is important, even if it is not quite as popular as Ubuntu among newbies.

Re:Fedora is important

[psykocrime]

Red Hat is important in only one way, from what I can see: they make Linux a commercial venture. Other than SCO, I don't think anybody has done a worse job from that perspective, either. Ximian, eventually bought by Novell, at least contributed to the development of Evolution and other GNOME software. Corel got into the Office for Linux market at a time when the biggest complaint about Linux was that there were no good applications available. IBM has contributed to the idea of commercial Linux more than anyone I can think of, both in terms of GPL-ed contributions to the codebase, and as a vendor promoting Linux-based solutions. Red Hat has been a purely profit-based venture, sacrificing the quality of the free distribution to make a few extra bucks.

Right, because Red Hat has never contributed anything to the community:

http://sources.redhat.com/projects.html

http://fedoraproject.org/wiki/RedHatContributions

Fedora isn't perfect, and RH did make - IMO - do a poor job of transitioning from the "old" RHL series to Fedora, but to suggest that they don't
contribute anything to Linux and OSS is just ridiculous.

Re:Fedora is important

[mandelbr0t]

I've installed many bad RPMs (admittedly, mostly prior to RPM v4, but I jumped ship to Debian-based distros around that time) that have destroyed the entire configuration to the point where no dependencies resolve correctly any more. All of the responses I've heard about this sort of behaviour are something to the effect of "use the source RPM then", or whatever. The point being, things need to be painless. Sure, I could debug the RPM database (occasionally I had success in sorting out what went wrong), but it's a nightmare to try and use RPM to install proprietary software. You almost always have to force the installation using --no-deps --force, because RPM binaries are usually targeted at a specific distro/version. I remember mysql had big problems too, and Red Hat wouldn't upgrade from 3.23 for an unreasonably long time. Oracle had problems, again with dependencies. The list goes on and on. I also started using Red Hat around version 4. I've got plenty of bad experience with them, believe me. I've also got some measure of experience with every one of the alternative distros I mentioned, and have good and bad things to say about all of them.

Debian takes a somewhat draconic approach to package management, simply refusing any further package installation until you resolve the dependencies. I've never seen distro-specific .debs, just one. There weren't many of them until Ubuntu got big, but you can find anything (including proprietary, non-GPL software) packaged in Multiverse. I've installed software from all sorts of different sources, and I've never had to debug the installation from the command line, which is the entire point of the exercise, isn't it? I don't mind the inflexible nature of this package management. After all, it is the authoritative packing list for your OS. I kinda want it to be accurate, for auditing purposes.

Maybe you just need some more Fedora experience.

mandelbr0t

Good ideas

[grub]

Makes sense that they plan their future. Pre-arranged funerals can ease the burdon on the survivors.

Oh wait, this isn't about BSD?

Fedora Legacy Dropped

[Vexler]

Apparently one of the results of this summit is the dropping of all support for past versions of Fedora Core prior to FC4, as a note on fedoralegacy.org said this past week.

I agree that we can't support all the versions in perpetuity, but I thought it would have been more helpful if they had included some reason other than "sorry, we just can't do it anymore". Did it not fit into the big picture of their support? What about future security fixes? etc. etc. As it was, it was very abrupt.

Re:Fedora Legacy Dropped

[Kelson]

I agree that we can't support all the versions in perpetuity, but I thought it would have been more helpful if they had included some reason other than "sorry, we just can't do it anymore". Did it not fit into the big picture of their support? What about future security fixes? etc. etc. As it was, it was very abrupt.

It's been hashed out on the mailing list. The upshot is this: Fedora Legacy depended heavily on volunteers. While there has been demand for them to release updates, there have never been enough volunteers to keep it going. This has been true almost since the beginning, but it finally got to the point where the people running the project looked at it, said "we really can't keep up, can we?" and decided to fold the resources available into the main Fedora Project.

As I understand it, the current plan is to drop Fedora Legacy entirely, but extend official support for the immediate previous release (which right now would be Fedora Core 5) for several months longer than the old EOL policy.

Re:Fedora Legacy Dropped

[Kelson]

Just to clarify, "the people running the project" in this case means "the people running the Fedora Legacy project."

Random Rule of Slashdot #843: The one time you don't use Preview will be the one time you should have.

Re:Fedora Legacy Dropped

[Nighttime]

From Internet News

Typically a Fedora Core release comes out every six or seven months. Red Hat's flagship offering, Red Hat Enterprise Linux (RHEL), by contrast, comes out every 18 to 24 months. Under the new lifecycle plan a Fedora Core release would have 13 months of support.

"Anything beyond this really seems to be corner cases that would really be better served by something like CentOS for free, RHEL for rock solid support, or Oracle for crackmonkies," Keating wrote. "What does this mean for the "Legacy" project? We feel that the resources currently and in the past that have contributed to the Legacy project could be better used within the Fedora project space."

Re:Fedora Legacy Dropped

[uglyduckling]

see, the way i see it, if you have time to migrate to another distro, you have time to migrate to the newer release of the same distro, but with less pain

The LTS bit of Ubuntu LTS means 'long term support' (sorry if you knew this). Presumably the parent's point is that he can switch to Ubuntu once and have 5 years guaranteed support for the server version, wheras upgrading to the newer Fedora/RH offering gives no certainty as to how long support will last. It's not always non-trivial to upgrade to a newer release, so if he/she is going to do it then they should do it once and stick with the distro for a few years.

No mention of users

[Intron]

All of the planning described in the article seemed to be oriented on how to best support developers. I didn't see anything about end user goals.

Re:No mention of users

[eln]

Also, with open source software, the line between developers and users is very thin.

Not really. The developers are the guys who write the code, and the users are the ones who bitch about it. Same as any other piece of software.

Re:No mention of users

[smoker2]

Fedora is all about developers because it is all about development

It has never set out to be a user oriented system. It only exists to push the envelope. If you choose to use it in any of its incarnations, you have to accept that. Otherwise, install RHEL or Ubuntu.

And no, that wasn't meant as a flame, it's the truth. Is Ubuntu based on Debian unstable, is RHEL based on FC6 ?

Re:No mention of users

[RAMMS EIN]

``Not really. The developers are the guys who write the code, and the users are the ones who bitch about it. Same as any other piece of software.''

While that's true to an extent, there are two things that make open source software different from the norm:

1. Many developers write the software for their own use (rather than for money)
2. Users can and do change the software to better suit them

This is what blurs the line between developers and users. Of course, both of these are also reasons why developers can and do ignore users' requests, and get away with it.

Re:No mention of users

[schwaang]

I think Red Hat is still working out how to allow real community involvement while still keeping control. And they seem to be making progress. If they get the balance right, maybe they'll end up with more people on their boards who will take users' needs into consideration more naturally.

Transparency needed to come first, and that's way better now. Fedora's governance was non-obvious, with a different Leader of the Week handing down Red Hat fiats. Now they seem to be consciously trying to expose more of the decision making process, and the leadership team seems more stable and active. This is all to the good.

I'd still like to see more voices on the advisory board that take the user point of view. You'll get some swinging dick who says "Hey let's just track all Fedora users so we know how many there are, and who cares if some people whine about privacy." And nobody is there to say: "Whoa there cowboy, we're not Microsoft yet."

But if they're moving towards more open governance as it appears, I think they'll end up hearing out their users' concerns more as a consequence.

The Fedora paperwork is the current killer

[Anonymous Coward]

I tried contributing to Extras this year. I gave up due to the paperwork. Wading through pages and pages of the Website, and following the instructions got me exactly nowhere. No response. No approval. Nothing.

Only later did I find out that I had to jump through some more hoops.

What would be helpful is a more streamlined, and MUCH better documented system.

Given the other packages which conspicously lack Fedora support, I suspect that I'm not alone.

I do hope this changes, as Fedora is my preferred distro. But right now, it is definitely hurting contributions to the project.

Re:The Fedora paperwork is the current killer

[gdek]

Yep. Which is why it's pretty much Number One on the hitlist for the new Fedora Infrastructure chief.

High time to stop duplication

[namityadav]

I think the first objective for all the Open Source teams should be to stop duplication. A lot of our resources are wasted in getting features ported from other applications and (Even worse) redoing features on different applications (Because of underlying differences). I know that one of the strengths of Open Source is to have "choices", but some of these choices are just plain silly. I am not asking for these choices to go away completely. But there should be at least some sort of coherence between different alternatives (They already have some coherence, thanks to the Kernel .. but we need to see a lot more of the same in more higher level applications too)

Imagine how much more work could be done to a package manager if every distro was using the same. Imagine how good OpenOffice and KOffice could have been if there were not 200 other Open Source alternatives. I am glad to hear about efforts to unify KDE and Gnome. We need to focus on something similar for a lot of other applications too. And this should be one of the top most priorities for Redhat, Novell, Ubuntu/Debian teams.

Re:High time to stop duplication

[RAMMS EIN]

I disagree. Having alternatives is healthy. Not only because of choice, but also because the competition between them provides incentives to improve them, and because if something happens to one, there's always another to fall back on.

The amount of duplication within the open source world is actually pretty limited, I would say just about enough to provide the benefits I pointed out earlier, and to cater to the many niches there are (e.g. some people want full-featured systems, others want simple ones, yet others want performant ones, etc.)

``They already have some coherence, thanks to the Kernel''

Err, well. The kernel is only a tiny part of the system, and one you don't typically code for directly. The personality of the system is actually much more determined by the standard library of whatever programming language you're using.

``Imagine how much more work could be done to a package manager if every distro was using the same.''

I don't think package managers are or should be so complicated that they'd greatly benefit from everyone hacking the same one. At any rate, the diversity allowed me to choose the vastly superior apt-get when most people were using rpm (I know there are working wrappers for rpm that resolve dependencies nowadays, but back in the day, there weren't). I'm glad about that.

``Imagine how good OpenOffice and KOffice could have been if there were not 200 other Open Source alternatives.''

Again, I'm not sure it matters much. I think adding more developers to OpenOffice.org will only contribute to the bloat, leading to new problems. Koffice seems to make great progress, despite the existence of various competitors (OOo being the big one). AbiWord was a good word processor years ago, before OOo existed, and I can't imagine it's gotten worse since.

``I am glad to hear about efforts to unify KDE and Gnome.''

You mean that they're standardizing mechanisms? I'm glad about that, too. Standards are good. So are alternatives. Both can, and should, exist at the same time.

OSS and natural selection...

[Junta]

Forks/duplications of efforts can have negative repercussions, but they are not without reason. A fork reflects a difference of opinion on how to proceed. Duplication of work occurs on similar goals, but one of two things happen. Either the reason behind the fork was not really popular or not sufficiently different to pursuade userbase and the fork dies, or the cause for the work was justified and the fork lives on or overtakes the original.

Can probably point out tons and tons of failed forks (I believe mplayer has had a few unsuccessful forking attempts). They happen all the time.

A shining example of a 'fork' like endeavor coexisting with the original is Debian and Ubuntu. Ubuntu has a set of technical and marketing goals that didn't mesh perfectly with Debian. Ubuntu was justified and the community has greatly accepted it. Meanwhile Debian has not really lost much in its userbase (most Ubuntu users come from RPM based distros rather than Debian) because the concepts Debian hold as important still matter.

And sometimes fork reflect the need to meaningfully continue a project that has for all intents and purposes lost touch. Xorg is a fork of XFree86 that has effectively killed off the original. They still twitch, but they've even taking down their ultimately embarassingly list of distros that still supported them (generally by not having updated yet rather than a concious future decision). The breaking point was a licensing technicality, but it's clear that XFree86 had technical problems as well in adopting new graphical features.

Hell, linux itself is spiritually (not technically) a fork of minix. The basic point is simple, projects by and large once established tend not to do revolutionary new things as the people at the head are heading basically where they meant to go. Forking is a logical way for revolutionary change to happen and the userbase decides the fate of the original and new.

Re:Fedora's imminent death

[joe 155]

"You won't be missed you corporate-enabling proprietary garbage"

I think you fundamentally missed the point of fedora there. Fedora is 100% free, so much so that it doesn't ship with mp3 or DVD support. It's a small hastle but it's the price of freedom... so not really proprietary

Re:Maybe, but it needs improving.

[jd]

I cut my teeth on those and have the fillings to prove it. :) Seriously, I've mucked with .spec files and written a few. The documentation isn't so much poor as virtually non-existant and you'll get far more information from grabbing good, working pre-existing ones. If you want anything compiled with the -march=pentium4 flag (may or may not be a Good Thing, depending on program) or to use optional libraries that need to be compiled in if present, then this is the way to do it. It's slower and more tedious to pick through than a simple ./configure script, but you can do it.

Slower? Yeah - you don't know if any of those patches touch the configure options, so you've got to get part-way into an RPM build, break out, find the source directory, find the options, go back to the SPEC directory, find the .spec file, find the call to configure, rebuild, realize that that fixed the wrong architecture, go back, fix the right architecture's call, rebuild, realize your new dependencies aren't correctly reflected, go back, fix the dependency list for the options you are wanting, rebuild, discover that the compiler doesn't include something that is needed, repeat all of the above for the GCC compiler, then rebuild the package for real.

Sure, I went through dependency hell with tarballs. The "golden era" was more brass-plated than gold. The number of problems was probably comparable, the only package I ever recall swearing at to this degree was X11R4. (Do you know how long that takes to build on a 386SX-16? Do you know what it is like to build the entire distribution tree, only to discover that due to some obscene/obscure bug when on the Linux architecture that random portions will mis-configure, mis-compile, barf on GCC or implode except when run on a non-existant resolution that causes the monitor to give a high-pitched scream and run down the street?)

Nonetheless, with the exception of X, most problems were quick to discover and quick to fix. (In fact, I have yet to get X to compile correctly with any serious platform-specific optimizations. I won't forgive the Berlin/Fresco group for abandoning their alternative GUI.) The same cannot be said of exactly the same programs managed through .spec files and SRPMs, as there is way too much detail in too many different locations within the .spec file, within the patches, within the build system itself and within interactions with any quirks thrown up by already-installed RPMs. Too many unknown variables and no clean way of finding out what they are.

Your error is not RPM's fault

[DragonHawk]

You almost always have to force the installation using --no-deps --force, because RPM binaries are usually targeted at a specific distro/version.

No. All binaries are targeted that way. When you run ./configure, it runs through a bunch of checks to figure out where things are and how they are configured, for all of the dependencies. And "dependencies" includes everything from special-purpose libraries to glibc and the kernel. It includes all the configure options, source defines, patches, compiler switches, and anything else that changes the configuration of the binary. RPM keeps track of all that stuff because that's the only way to be sure it will work. If you change any of it, sure, the resulting binary *might* *appear* to work, but it might just as easily segfault.

Binary compatibility is hard.

The "--force" switch tells RPM, "I know you think this is a bad idea. I say I know otherwise. Do it anyway". You can't then turn around and complain that things broke when you did that. RPM took your word for it when you said you knew better. If you didn't know better, that's your own damn fault, not RPM's.

Put more briefly: If you think you need to use --force, you're almost certainly wrong.