Re: Drop testing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> #include <hallo.h>
>
> * Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]:
> > > #include <hallo.h>
> >
> > IMHO it's somewhat silly to "stop the experiment now" and drop
> > testing. Although there are problems with testing, there *are*
> > well-known positives of having it.
>
> All the known positives are outweighted by the negative issues as
> described before.
I don't think so.
For me, existance of testing allows running more-or-less up-to-date systems
without facing current development problems with packages/subsystems that
I'm not involved in.
For a long time, I use mixed (stable/)tesing/sid systems. Most of packages
are from testing, sid version is used for a package if testing version
doesn't fit for whatever reason.
This proved to work very well. I think many developers and technical users
do the same, if they don't they should probably try it, because it really
works well.
In fact, existance of testing allows me to be a user and a developer at the
same time.
You may state that such reason has nothing to do with release process, for
which testing was originally proposed. Yes, I agree. However, the above
argument shows why testing *is useful for real life* even in it's current
state.
As for role of testing in the release process, I believe there is plenty of
room to improve.
You write, biggest problem with testing is outdated packages. Yes, probably
you are right. So, some action should be taken to overcome that. I can't
immidiatly answer what exact actions will help, but it's a good direction
to think on. Let's try.
So what makes package's path to testing long?
- - RC bugs. Here nothing else could be done other than fixing the bugs.
Personally I thing that some infrastructure change could be useful here to
force maintainers fix RC bugs. Probably any RC bug without activity for
several (say, 5) days should "become more public", some mechanism should
be used to encourage non-maintainers to work on the issue.
- - Complex dependency chains. Probably some scheme could be used to decrease
the effect of those. E.g. build mostly against testing, not against sid,
and use build-deps from sid only if relly required (what exactly "really
required" means here, should be defined separately).
- - Arch de-sync. Can't some mix of cross-compilation and more work on
toolchain issues improve situation here? I'm currently involved in
dpkg-cross, and I see some interesting possibilities here.
- - What else?
> > Unless such analysis is done, almost any discussion of this topic is
> > pointless. Period.
>
> A-Ha. How long does Testing exists? And why did nobody write this paper
> in the meantime? Why do you not try to do so? I describe the facts. Not
> some imaginary proof that will never see the daylight. Period.
I don't know why nobody did such analysis. (Probably someone did? I'd love
to read it!)
As for myself, I don't feel I understand the problem deep enough. Although
I follow debian developent for many years, I'm only becoming to be
involved :).
I tried to write something just now, see above. I may try deeper analysis
later, however someone with better understanding of details could do that
better.
> > But such analysis should be done *after* *sarge* *release*. Flaming
> > now will only postpone the release and do nothing more.
>
> As described before, it is too late to stop this discussion.
Just take action on some RC issue before you write next message to this
flamewar :). If everybody does that way, having such a flamewar will be
the most effective BSP in Debian's history :).
To be honest with myself, before writing this mail I've looked through the
list of current RC bugs, found one that was last posted long ago, and
submitted some information there that is probably enough to resolve the
issue. That was bug #274873.
> But many maintainers simply do not care much
> about testing, Unstable runs fine for them.
Do you really think that this is the point? Do you have statistics?
My feeling is that many more maintainers don't take care much about their
packages, and testing/sid issue has nothing with this. We have currently
at least hundred of thousands of bugs open. Say, half of those are
wishlists and probably shouldn't count, but the rest 50,000 are issues
that require action! Many are open for months and years.
Nikita
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBfA3bv3x5OskTLdsRAu/wAJwOkabMCf7xca0sB5RFEaxPCKverQCgvM9i
HWrXyk6RkAFJhhxenNi3pLk=
=R+6W
-----END PGP SIGNATURE-----
Reply to: