-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eli Wapniarski wrote:
On Tuesday 27 January 2009 02:18:01 José Matos wrote:
> When was the last time that rpm failed on you?
Thankfully never.
Then did it matter that it was an RC release?
> Clearly if the maintainer of rpm that is also the packager for
Fedora has
> decided to release it for a stable version of Fedora why is he wrong?
Because it has not been deemed stable. With all due respect and release
deadlines not withstanding. Look if it ain't stable it ain't stable. For
what ever reason. Some minor feature or cross platform whatever.
And just how are
things getting deemed stable? Unit tests can't do
everything and developers are usually strained for testing every
configuration. Sometimes the best way to get real feedback is to put it in
the wild where most things work. AFAIK, the only things that broke were the
blobs. But there's a chicken-and-the-egg problem with those. nVidia won't
release a driver until the server is in use (why work on something nobody is
using?), but if we wait for them, users of working drivers are out six
months for an upgraded X server. Why hold up people using free software
for a company that won't play ball?
> Ignoring that developers only care about Fedora when developing
software
> it is not what you thing but it is what you are implying, because
for you
> stable means in the context of Fedora.
No.. Its not what I'm thinking at all. What I am trying to get across. Is
that developers under the gun of deadline pressures should not give into
the temptation of releasing when the product is not ready. Developers
should not give into the temptation of releasing "good enough" software
that they are not sure is stable and rely on users to do the qa.
Regardless of whether the decision is intentional or a product of release
pressures.
When the jump is a major change (I'll use gcc-4.3 as an example), it
may be
too late if the deadline isn't reached. If 4.3 hadn't been pushed to a
release, at some point during the release, there would have been an upgrade
of everybody's packages for the massive rebuild that has to be done for
such a change. Since that is not really acceptable, it would have to wait
for the next release. That makes it 6 months late and people who wish to
(for example) test their code under C++0x either has to mix rawhide (not
supported/recommended) or run rawhide (eats babies and nothing is
sacred). That's not an option either for most, even developers. Granted, 4.3
wasn't really close to a deadline, but had it been, pushing it a little
early would have been the easiest course for most people.
> You can not complain that 4.0.0 (deemed releasable by the
developers)
was
> beta because according to your previous comment 4.0.0 was
"stable"
(for
> some definition of stable). That means that we only trust the
stable
> versions sometimes?
I'm not complaining about that it was deemed releasable. What I am
complaining about (and not only about Fedora, but KDE as well) is that it
released as a "stable development release" which was obscurred. And
even
currently while quite usuable. There are a lot of rough edges that
push
the use of more and more gtk apps. Konqueror being the main culprit. KDE
still isn't KDE friendly so to speak.
What specifically are your problems with
Konqueror? The only thing I end up
using Firefox for is flash and sites that don't play well in Konq. KRunner
using it's bookmarks/shortcuts (not Firefox's), startup time, sharing of
adblock with akregator, using system file associations (don't know how
Firefox continues to screw this up day in and day out), and other things
makes Firefox used only when I'm forced to. Memory usage can be an issue,
but Firefox increases its total memory usage faster, so it's a tradeoff
there.
> Surely I know that kde developers warned about 4.0.0 but I have
seen
> other cases where that warning was not present.
>
> Notice also that different programs have different dependencies and
using
> compatibility versions is not an answer, or else the complexity
of the
> system would grow up quite easily.
That may be true... But like I said... If it ain't stable. It ain't
stable. And if there is no way to go back. Then sorry -- We will serve no
wine before its time -- makes a lot of sense.
And just what piece of software is
100% stable? There has to be some point
at which a release is made and the saying is "release early, release often".
Early adopters get burned in every market (price cuts, new versions, etc.).
At least here we can bring everyone up to speed once those who have
tripped get helped.
- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkl+r5MACgkQiPi+MRHG3qQB9ACeMWpgH0LtFwwJAQGOllpuVDwx
dA4AoI1nTiUli4JiVdH7TXjgv8XsWoTk
=Nl38
-----END PGP SIGNATURE-----