Slashdot Mirror
Neither Stable Nor Unstable: A Midrange Debian?
truefluke writes: "This was forwarded to me, from a friend who is a very loyal Debian supporter, with the cool news that Debian could become 'more up to date more often'. This news appeared here on the
Debian news source. A good idea, and prob incentive for more folks to try out Debian without resorting to the old saw of 'too old / too slow.'" Debian developer Anthony Towns says in the list posting mentioned there that "[t]his is a (mostly finished) project that will allow us to test out distribution by making it "sludgey" rather than frozen[.]" Sounds like the same logic behind the Caldera "Technology Preview" and Red Hat's Rawhide -- give people more of what they want of The Bleeding Edge, without getting reckless with the official release.
As others have pointed out, using testing will not be like upgrading to unstable every week.
:-)
I like to upgrade horrendously broken packages to unstable on wednesdays. If you happen to upgrade to unstable every thursday, you get a freshly broken system each week.
On the other hand, if you upgrade to testing each thursday, you won't get the nasty broken package I just uploaded.
Big difference.
"A new tree just seems like it will cause more work for the Debian people who(no offense) tend to move a little slowly already."
The really neat thing about AJ's work on testing is that it's intended to be populated automatically. It will surely create a bit more work, but he has all sorts of smart code that ties it in with our bug tracking system so it can find out that the package I uploaded last wednesday is buggy and shouldn't go to testing; and more code that makes it smart enough to realize that the other 10 packages I uploaded this week that depend on that new, very buggy package, cannot go into testing either. It's very cool.
--
see shy jo
There are plenty of people out there who are hard core Debian developers, or are simply interested in seeing the latest and greatest before anyone else. These people, although a smaller group than those interested in running a testing build, will be willing to run unstable. It's all part of the geometric series of the number of people using any given piece of code, as in this example from a commercial company:
A new class: 1 person, the developer
Added to internal build: 100 people, the other developers
Alpha given to interested customers: 1000 people
Beta with wide distribution: 10,000 people
Release: 100,000 people, everyone
With debian, the series was getting inverted. The unstable branch was stable enough and had enough new features that it was a better choice than the stable branch. This is not what you want unstable to be used for. In order to restore the "normal" order the Debian folks decided to make a "good enough" version that is suitable for many people to use. Sounds like a sensible idea to me.
Walt
Who needs a bloody ISO? Just grab http://http.us.debian.org/debian/dists/(pick one)/
/main/disks-i386/current/image-1.44. Debian does require a bit of fiddling to install without a CD, but I actually like it better that way. As for wget + proxy,
Keep it on a spare partition if you can manage the space, and get rescue.bin and root.bin from the
export http_proxy = (proxy name)
wget --proxy=on [--proxy-user=user --proxy-pass=pass] -r (url)
I've never understood why they do releases anyways. It is mostly a compilation of other peoples' software, so why not just test each indivitiual piece, along with the packages that it depends on, and if it's stable enough for public consumption, put it in the stable directory?
To get something done, a committee should consist of no more than three persons, two of them absent.
Really. I hardly ever have actual problems. In fact I wish it were *more* unsatble so that I could get upgrades of all the new actual development versions of various software like the kernel and friends. Personally having access to things like the newest lynx code in official .deb form wold be a plus. Maybe even the development versions of various GNOME apps and it's core code. Or how about updating the Xfree stuff every week like they have for the WINE code.
Respond to s
Founder's Camp
Founder's Camp
News for non-Nerds. Stuff that matters.
-current
-release
-stable
hmmm..., when will the world learn?
How about "`slushy' rather than frozen".
I noticed, when I read the thread originally, that there is some concern that this would take testers away from unstable. But I did not notice the counter-argument (which I happen to fall into). I'd love (really) to test more, except unstable is too unstable. Buggy I can handle, but not working isn't cool. I think this testing dist. would brin MORE testers in from stable.
Just my opinion, I've emailed my support and opinion, perhaps others should send their support for the idea to debian-devel.
I think this is an awesome idea, and I really hope it is formally implemented.
--
M
of open source is, that it is marked as "stable" when and only when it is really stable (and not when marketing has decided to ship the product), and yet you can still have your bleeding edge program when you like it. But dividing this into three different states is likely to confuse most people. It is better done if you obey the rule: "release often" (Eric Raymond). During testing phase you will find out which of these "unstable" releases are just "stable enough" to be used (that is, it is in the same state as most commercial software...). In Linux mailing lists, you'll see sometimes postings like "2.3.XX" is a stable version, use it if you really, really need feature YY". I think debian should use the same rulings. Just produce more developer releases, and if things turn out to be good enough, tell everyone about it (with a few warnings left). Its is better to be more specific: either, it is stable and tested and ready for the masses, or it ist bleeding edge where feature X works, feature Y is broken, and Z is useable if we have full moon. You just know what you're doing. And if you don't know, don't do it, even if it might work.
You found a sword: +4 damage, +5 moderator points