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