Shhhhh! If you're quiet, Linus Torvalds might release a new Linux The world almost certainly needs to wait another week for Linux 4.9, says the operating system's overlord Linus Torvalds. In his weekly post on the progress of the next kernel release, Torvalds announced release candidate seven of Linux 4.9, saying “ I think we got all the silly problems I was aware of fixed, and on the whole …
> One thing I've never understood is why software is released with known bugs
In addition to the already noted: changes (including bug fixes) often introduce new bugs, there is also the problem that many bugs are benign – no one is affected – and the change adds risk (the new bug could be far worse).
There is also the case where an issue is found late. Should the release be delayed for that fix? (Especially true of test releases.)
Contemporary software systems are very complex. Even a small system will have tens of thousands of interacting parts. Mostly these do not interact (much effort is put into avoiding interactions) but sometimes they need to, and sometimes they do unexpectedly. Any change can potentially trigger an unwanted interaction.
Suppose that several new bugs are reported every day and it takes a minimum of several days to get a fix reviewed and approved (just an example; I'm not claiming those numbers are accurate for Linux). What you could do is make a release branch, freeze that branch, and wait for the bugs reported against that branch to tail off, but then you may end up with a release that for many users is too out-of-date to be interesting.
One thing I've never understood is why software is released with known bugs.
Software is very complex. Some of the most complex things humankind has ever tried to construct. If we refused to release it until everything was perfect you'd be waiting a long time for it. So we have to be pragmatic and choose a level of quality based upon the target market and what that market will tolerate.
"One thing I've never understood is why software is released with known bugs."
Because known bugs vary by their severity and their ability to happen. If a bug causes a kernel panic once in a blue moon on some esoteric setup, do you delay the entire release for the sake of that?
More severe bugs will be regarded as blockers and the release will be held up until they are fixed. Other bugs might be prioritized to be fixed in a subequent release.
The adage "never buy version 1 of anything" also applies. This doesn't just affect software either - a brand new model car is riddled with flaws and quality issues. Many of these are known about and others will be found as cars come in for repair or get crashed. Only the most serious issues will justify a recall. Other issues will be fixed during the production life of the vehicle.
This is not a release it is a release candidate, ie a test/trial to shake out any bugs.
The point is that Linux kernel development happens in public view; with most (closed source) software these release candidates would not be seen outside of the organisation that writes it.
"with most (closed source) software these release candidates would not be seen outside of the organisation that writes it."
If only that were true. Too many times, closed source software that'd barely qualify as a FOSS early Beta is shipped as "the latest and greatest".
Unfortunately, as AndrueC stated above:
"So we have to be pragmatic and choose a level of quality based upon the target market and what that market will tolerate."
And the Market's been trained to tolerate some pretty shitty quality software.
Supply and demand. People install software with known bugs.
There is no value in being more picky than your users. Give them the choice.
I guess the users that care will consider if the way in which the known bug might affect them is worse than the benefits (and fixes) in the new release.
I guess my server doesn't care if there is a V4Linux regression.
If Linus thinks that he'll end up pushing out another release, then to my way of thinking, this one isn't a release candidate. It's a beta, or possibly a preview. A release candidate is one where the developers think it's of sufficient functionality and quality to be released.
> If Linus thinks that he'll end up pushing out another release, then to my way of thinking, this one isn't a release candidate.
Alpha -> not feature complete
Beta -> feature complete, buggy
RC -> release candidate, most bugs have been fixed in beta stages (known minor bugs will be addressed in patches), this candidate is there for the testers to yet again test, are there any late showstoppers ? If not, release it! Small issues will be fixed in patches later ...
In theory, you would only have one RC, however, practice dictates you'll have several, patches sometimes introduce new bugs, testers find more bugs ... showstoppers ( newly found severe bugs) mean you have to create a new RC.
Try these definitions and it may make more sense:
alpha: many features missing, those that are there may not be even vaguely complete. There will be massive functionality holes and gaps and loads of bugs.
beta: most important features are present and generally are functionally complete. There will be functionality holes and gaps and many bugs
release-candidate: all features for the release are present and functionally complete. All the in scope functionality will be present and it should all work but there are potentially significant bugs, but we may get lucky and decide the bugs aren't serious enough to block the release.
release: all features for the release are present and functionally complete. All the in scope functionality is present and there were few enough bugs to justify releasing it.
The key thing is that alpha/beta releases may get entire new features, whilst release-candidates should only get bug fixes.
"But if you think that the software that you have now will need more changes before final release (which is what Linus is saying), then by definition, the current software can't be a release candidate, since you don't intend to release it (as the final product)."
I see what you're saying. But Linus is just talking about how he "feels" about this particular RC. He expects it will fail testing in some way and that there will be another RC afterwards.
But that is just a feeling, and the current RC may pass all tests quite adequately.
By advertising this feeling to his team, he is asking them to really, properly hammer this RC in testing, and he is also making sure they are ready to expect to have to patch more bugs (as opposed to going in to "holiday mode"). This is simply good, transparent management and effective communication.
Yes, bugs come in a variety of severities...
Yes, many bugs are not very tolerable, and result from unknown interactions between things, and with Linux growing in complexity the number of interactions grows as well (and that is just the kernel!). Sometimes bugs can be a bit esoteric and for the most part benign. An example I noted on an operating system from long ago (the 70;s) was that leap year was calculated when the date was manually entered on the console (at boot time). This would have bad effects if the date were entered in December of the year, and the machine ran continually for another two months (till February 28/9th). Since the leap year was for the year before, it might think that Feb 29, 2017 existed (no it doesn't, I know). Sure this was an esoteric bug, and AFAIK it was never fixed, because reboots happened more often than the two month interval necessary for the bug to appear.
This is why some software is released with "known bugs". They are ones that usually 1) Aren't commonly seen, or 2) Have work-arounds that are acceptable to the user base. They are usually documented as well.
Then again, I have no idea how Microsoft and Windows do their releases, or if they follow any of these "reasonable" practices about "known bugs". Such is life.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
