Ooops, we made Linus leave : (choices and punishment)

[Ben Boeckel]

-----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-----