Fedora's mid-life crisis -- YUM v. APT v. SmartPM
Bryan J Smith
b.j.smith at ieee.org
Tue Aug 7 15:42:01 UTC 2007
Paolo Mureddu, Gian wrote:
> Thinking of Fedora and Debian as black and white (not necessarily
> respectively), anything in between would be the "gray area".
This is going to be my last comment on this subject.
To start ...
I tend to not try to use abstract terms and stick with tangeable ones.
E.g., as an electrical engineer, I know anyone who uses the term
"renewable energies" doesn't have the faintest ideal about them.
Same deal here, I don't like to use shades of the spectrum.
I think Debian and Fedora come down to their simple realities.
They are established, proven, well-regarded (among long-time
Linux consultants, sysadmins, etc...) with a steady stream of contributors,
solutions providers, etc... and a lot of the reason is the release model.
Red Hat Linux 4.0 through Fedora 7 is 20 releases, all done very similarly.
Rawhide through Beta/Test on to the 6 month typical cycle (sometimes
5, a few 7 and even 8 months) for a full decade now.
And that includes the 3rd or so release after 18 months being the
"trailing edge" and well trusted and standardized on.
And when companies showed they were willing to pay for 5+ years
of support by buying SuSE Linux Enterprise Server (SLES) as a
"separate product," Red Hat dropped its SLA model after Red Hat Linux
6.2 "E" and we got a separate product.
But the community, development, package test (Rawhide/Devel),
integration/regression test (Beta/Test) is unchanged.
It has been, and only continues to be increasingly, community-based and
driven, with strategic direction and objectives focused on the
18 month, stable release.
It's easy for one to say "community focused" and its highly subjective.
Something has to drive that and, as we saw with one too many Red Hat
and Debian off-shoots, defining that long-term is a real issue.
A lot of these off-shoots leverage the testing of Debian/Red Hat to start.
But by the 4th or so release, they've forked so much they lose
that leverage and find themselves in the realm of their own integration
and regression testing. That's not "fun" stuff in the traditional
engineering lifecycle. And it only gets worse.
Software built (ABI) or even written (API) for older releases no longer
run on newer releases, there are compatibility and upgrade issues too.
Repositories quickly become "dumping grounds" and that's when it hits.
The distro, correctly, tries to enforce some basic release controls.
And guess what? That's when the "newness" wears off and they
aren't "fun" anymore. And those contributors go "they are as 'bad'
as Debian/Fedora now."
Debian and Fedora aren't "new" and a lot of new maintainers balk at
things, necessary evils of the traditional engineering lifecycle.
One of the reasons I haven't attempted to submit my own packages or
become a maintainer is because I know what repsonsibility comes with that.
And if that is what others have a "problem" with Debian and Fedora
(and trust me, I'm a "lurker" on many lists and I see it a lot),
then we either need to "key them in" on those realities, or let them be.
If they are the latter, they will get tired of Ubuntu soon, especially
as more and more of the Conical criticisms take hold like those
not so different from what we see of and towards Red Hat.
Especially when Conical starts to "clamp down" on the "run-away" development.
I've seen a lot of complainers of 7.04 from 6.06, and that's just the start.
I like Xubuntu and have no problem with Ubuntu, but I think too many
people are spewing the same things I've seen out of many other Debian
and Red Hat / Fedora forks over the years, and those same people
come back to criticize the same "new" distros they loved.
The contributors and maintainers that are long-term stays are those
that appreciate the processes and relase model, with all their overhead,
that go into Debian and Fedora. Or they seek not to fork, but to stay aligned
as closely as possible because they are fully aware of the testing load when
you do not. Heck, a quick trip to the CentOS list will let you see a lot
of people screaming for forks and packages, or "new features."
I stupidly tried to explain things a few times on there, and only
"the old dogs" seemed to know what I was talking about.
Anyhoo, with that all said, people who want Apt or Smart or
Foo Package Ultra-Better 3000 to be the default need to get involved.
That means taking on the Anaconda integration, RHN integration,
various, existing Python libraries and facilities to "drop them in," etc...
People complain about the types of responses in feature requests.
If you don't like the responses, contribute and prove them wrong! :)
Last post on this, promise. :)
Bryan J Smith - mailto:b.j.smith at ieee.org
Sent via BlackBerry from T-Mobile
More information about the marketing