+++ Yann Dirson [03-11-18 22:54 +0100]: > On Tue, Nov 18, 2003 at 07:29:29PM +0100, Adrian Bunk wrote:
> But that last point raises another issue: does anyone really use > testing ? Would anyone use pre-testing after all ? I used testing for a couple of years on my laptop and non-critical machines. I found it a satisfactory compromise between the 'too old' of stable and the massive churn, ever-changing packages and general need-for undating and maintenance of unstable. The primary reason I changed was the 'no security for testing' problem. So I have moved them both to unstable, but it's a lot of extra work and downloads for little gain (I get new packages sooner which is interesting but rarely actually useful) - the only other advantage I get (and the secondary reason I changed) is that I can do test-builds of my packages before uploading on an unstable machine. Doing my builds on a testing machine, then uploading to unstable can mean I introduce packages compiled against the wrong library versions. Source-only uploads would solve this and I could do test-compiles on some debian machine. So I'd say yes, testing is useful to real people, especially those with low-bandwidth net connections but for whom stable is a bit too old. The only thing we need to change to make it more widely useful is to make security updates happen for it in a timely fashion. That would be a sensible use of resources I think. More people using testing ought to help keep it releasable. > > Is testing actually worth the effort? > I suppose many of use have a number of problems to mention. Could we > just (attempt to) list them all, and see if they can be fixed easily ? > Or if they require some in-depth restructuring ? > > I'll start with: > > - build-deps are ignored, causing unbuildable stuff > => handle build-deps in exactly the same way deps are Could someone explain to me why this is the case? Was it an attempt to get things into testing faster that if build-deps were honoured, or was it just expediency. It does seem more sensible to enforce build-deps too to me, but I may be missing something. > - insufficiently-narrowed deps, causing stuff to migrate where it > should not > => this looks like a real non-trivial problem to me. Ideas anyone ? Obviously it can be tricky for a maintainer to get right as they can't necessarily try all (any!) of the possibilities but it should be aspired-to. On the other hand, in my experience build-deps are sometimes unecessaily-narrowed and require new versions of things for no particular reason I can determine. I suspect the shlibdeps automation contributes to this? > > testing with its lack of security fixes, aprox. 500 RC bugs and daily > > changing packages is not usable for production systems. > > What's the problem with daily changing packages ? By nature, only > different packages can change each day. That could make it a good > compromise between stable and unstable, eg. for people in need for > up-to-date desktops. But precisely, one of the problems for those > people, is that _some_ packages _do_not_ change rapidly enough... It's all a compromise, but it's a useful compromise IMHO. It makes sense to me to view testing as a releasable version of unstable and try to keep it that way as much as possible. Build-deps being added to the unstable->testing migration criteria seems to me to be the most fundamental change needed to make that more true, and security support to make it practical for people to use/test in the real world. All the above IMHO as I don't claim to have a deep understanding of all the dependency and trnsitionning issues. I do have an interest in consistent buildability for embedded Debian though. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
