dE . posted on Fri, 29 Mar 2013 19:28:37 +0530 as excerpted:
> You can even look at Gnome. They test their major releases for full 6
> months, and release a beta every month.
Sort of like kde, if you consider the last bugfix release of a series the
"release". Actually, that's pretty much what some distros do -- they
take the last release in a cycle (or penultimate, but incorporate most of
the fixes from the last release in their own testing cycle), and add
their own fixes on top of that.
In a way it makes sense, since part of the whole 4.0 release argument was
that it's just arbitrary numbers, and kde's users (primarily distros not
end users, except for distros such as gentoo that expose the choice to
the site admin as end user) pick the stability point at which they're
comfortable in any case. Of course that didn't go over so well with 4.0,
but the same general idea continues to exist and to work somewhat better
with the series releases, with many distros running the last bugfix
release (4.9.4 or 4.9.5, etc) of upstream's stable cycle, effectively
making the earlier kde releases in the cycle (4.9.0 or 4.10.0, thru 4.9.3
or 4.10.3 at least) rcs, with kde's pre-releases then being betas (kde's
rcs) and alphas (kde's betas).
The point being, the user (generally the distro, except for distros that
expose that choice to the end user, and of course those who build kde
themselves) picks the point at which /they/ define it as "stable enough",
regardless of whether that's the first kde beta pre-release or the last
stable series release or somewhere in the middle.
Of course here, being the leading edge guy who's almost always running
/something/ pre-release I am, particularly now that I moved off of kde
for my seriously mission critical apps, I'm always looking forward to
that first beta, raring to go! But of course I appreciate the fact that
I can fall back to the then middle-of-the-stable-series previous feature
version (4.x.3 or so, usually) if the kde beta release proves TOO beta
for my needs. =:^) I actually did that with a couple packages in one of
the stable series releases (4.6.2, IIRC) at one point, falling back to
the previous version (4.6.1) and masking the later version, due to the
problems in 4.6.2.
(That was when I was still running konqueror as my primary browser, for
one thing, and somebody committed something to the stable/bugfix series
that should have gone only to the trunk/dev version, triggering
konqueror's infamous double-submit issues it had at the time. That
wasn't the worst of the problem, however. Everybody makes mistakes. The
worst of the problem was that unlike a SERIOUS browser, even knowing the
problem relatively quickly, it took TWO FURTHER BUGFIX releases, thus TWO
MONTHS to get it fixed. This on a browser I was at the time using for
Internet shopping, banking, and bill-pay, where a double-submit could in
theory mean paying twice for whatever. That was when I realized, based
on some dev comment or other, that even part (all?) of the kde/konqueror
devs don't consider it more than a toy -- they use firefox or chrome/
chromium or whatever, for their SERIOUS browsing, bill-pay and the like.
Of course this was on top of the lack of proper SSL certificate
management in konqueror for several entire "stable and ready for ordinary
users" feature series, in a time context when entire certificate
authorities were getting blacklisted! Again, no big deal for a "toy"
browser, a proof of concept demo not intended for serious use, bill-pay,
banking, illegal dissident connections to out of country where the user's
LIFE could depend on the integrity of the SSL connection, etc.
Fortunately the latter didn't apply to me, but I was definitely using
konqueror for internet shopping, bill-pay and banking! No more!)
(But I had that bug "contained" rather early in its cycle, ultimately by
switching to firefox as my primary browser, tho I still used it for more
trivial browsing for a few releases, but it's not even installed now.
The packages that I actually reverted for a time were plasma related. I
even switched to the live version and git-bisected down to an individual
commit for that bug, a panel that wouldn't stay where it belonged. Then
I generated a patch reversing that commit and ran with it applied to the
current release version, 4.6.2 IIRC, for a bit. Then a different user
CCed on one of the related bug reports came up with a work-around, using
kwin window rules to fix the panel in place, which didn't work for me
exactly as he suggested, but that was the hint that let me create a
slightly different window rule that DID work, and I reconfigured my
panels a bit in the process as well, after which I could run the current
package without a problem. But IIRC, the bug continued to appear for
some users for the rest of the 4.6 cycle and into 4.7. Various bandaids
were applied in the code thru 4.8 or 4.9 or so, when I think the ultimate
bug was finally rooted out and squashed, based on comments to the various
related bugs, as I was still CCed to them.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
