Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Debian testingDebian testingPosted May 5, 2004 19:29 UTC (Wed) by rfunk (subscriber, #4054)In reply to: Debian testing by tjc Parent article: Revealed: how Fedora and the community interact
I'm not suggesting sticking anything in "testing." The mechanism isn't important. You're talking about client-side smarts vs server side smarts, but the end result of what's installed on the system is really the important thing.
What I am suggesting is adding capabilities to apt so that updates can be delayed for x number of days in the hope that major problems can be avoided. But you need to do more than hope if you're going to avoid major problems. During that x number of delays, major problems may be found, but they may not be fixed yet. What you're proposing is to go ahead and get those packages even with known major problems, rather than wait until those major problems are fixed.
(Log in to post comments)
Debian testing Posted May 5, 2004 21:57 UTC (Wed) by tjc (subscriber, #137) [Link] The mechanism isn't important.Yes it is. If capabilities are added to apt, then there is no additional maintanance for the pool. It gets the same files, just delayed by an interval selected by the user. What you're proposing is to go ahead and get those packages even with known major problems, rather than wait until those major problems are fixed. No, that's not it either... What I would like is some time to find out that a problem exists before I install a package. If I could hold updates back for a week or two, that would provide some time for major problems to become known. Finding out that a package is messed up after it has been installed it isn't all that helpful.
Debian testing Posted May 6, 2004 9:47 UTC (Thu) by boomi (guest, #21418) [Link] > Finding out that a package is messed up after it has been installed it isn't all that helpful._Someone_ has to find out. If you use unstable, you agree to help discover bugs in new packages. Use testing if you don't want to do that. Btw: old packages are stored in /var/apt/ archives, you can easily restore an old version. Using unstable? You are asking for trouble. Which is a good thing, someone else won't have the
Debian testing Posted May 6, 2004 15:20 UTC (Thu) by tjc (subscriber, #137) [Link] If you use unstable, you agree to help discover bugs in new packages.I don't recall entering into any such agreement. :-) Use testing if you don't want to do that. Testing is too old for my taste. By the time it becomes stable, it will be nearly obsolete. It's sort of the worst of both worlds in that respect. There's a big gap between "testing" and "unstable." It's within this gap that Fedora Core and Mandrake exist. Debian could probably increase the size of their user base by a significant amount by filling this gap. Personally, I use "unstable" on my workstation, but I keep a partition with Fedora Core around in the event that "unstable" becomes too much of an adventure. I wait for the dust to settle, and come back in a week or so. This happens about once a year.
Debian testing Posted May 10, 2004 9:55 UTC (Mon) by mbanck (subscriber, #9035) [Link] There's a big gap between "testing" and "unstable."I don't believe this is true right now. The release team is doing a great job nowadays resolving problems in testing when two packages keep each other out and so. It used to be quite bad when only AJ was looking after testing, but since we have a couple of very bright "Release Lieutenants", things are moving quite well. For example, it used to take a new glibc package months to enter testing. Last week, 2.3.2.ds1-12 entered testing after being in unstable for just two weeks or so. I agree that stable might be too old for desktop use (I have to use it myself at work), but testing is only lacking behind only for some corner-cases, while it is quite uptodate in general. Michael
|
|||||||||||