[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

package trees



This will probably get me ejected from the planet or accused of not understanding how Debian works, but here goes.

There has been a long standing "bitch" by some that Debian is so vary slow to update their base system. Personally I stand entirely behind the philosophies of making stable really stable and releasing updates when they are ready.

I would not want anything to interfere with this as I believe it to be one of the greatest assets of Debian.

But...

I recently got burned a few times when I would skip an update to testing. There are some dependency problems I ran into where I had to jump to unstable in order to get all the right versions of the right software. And some of them were less stable than others.

I started out by writing this with the idea that creating an intermediate level between testing and stable would be a Great Idea. Then it occurred to me that I might already have that if I set my apt_preferences accordingly:


For Example
----------
Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=testing
Pin-Priority: 600

(as long as they are both >500)

A little more thought on the matter came up with another qualifier on the testing packages. The assumption is that the longer that they have been in testing, unmodified, the higher the probability is that they are more stable than not. Mind you, this is an assumption and I know that there will be exceptions to this.

But I guess this comes down to a point. Is there any information available which implicates how long a package has been in testing?

This would allow a finer tuning of package downloads to assume anything over XX days to be "good enough to play with". The value of XX would depend on my willingness to meddle with that particular machines stability.

I have a number of workstations that I consider as different levels of stability. My notebook is pretty ruthless, I would probably set XX == 7. My desktop workstation is different and that might run > 30 days. You get the idea.

From a server application standpoint this might be inappropriate, but I am assuming that a lot of people like workstations that are closer to the bitter bleeding edge than other boxes in their network.

I think that the Debian community could also benefit because it would allow the user-base, our best source of testing/debugging, to find their own balance between stability and testing and allow a potentially greater cross section of test environments while the packages remain in testing so that the submission to 'stable' isn't met with a flood of bug reports. Again, I am assuming this flood exists with no actual knowledge of the same.

You would have the ability of testing packages to be slowly rolled out into a larger and larger user-base over time. As an example:

Under 'unstable' you might have 100 users test
Under 'testing' you might have 1,000 users test
Under 'stable' you might have [all] users test

If you could "feather" the testing age you may approach:
Under 'unstable' you might have 100 users test
Under 'testing' you might have 1,000 users test
Under 'testing' + 30 days you might have another 1,000 users
Under 'testing' + 60 days you might have another 1,500 users
Under 'testing' + 90 days you might have another 2,000 users
Under 'stable' you might have [all] users test

This could allow you a significantly larger number of eyes looking at your testing packages before they get into stable.

Would this provide a faster/better path to migrating to stable?
--
We will have solar energy as soon as the utility companies solve one technical
problem -- how to run a sunbeam through a meter.



Reply to: