Re: woody is getting worse...
On Wed, Oct 17, 2001 at 01:09:53AM -0700, Adam McKenna wrote:
> > So we should throw out testing because this particular bug slipped
> > through?
>
> No, we should stop bugs like this from getting through, because they degrade
> the value of testing.
>
> > Don't worry, I do indeed regret that this bug made it into testing, if
> > for no other reason than that all the personal attacks are exasperating.
>
> For the record, I'm not personally attacking you, I just happen to think you
> made a bad decision by letting this bug slip into testing.
That's what testing is *for*. It's for making sure that oversights and
things that "should work" really do; for catching the slip-ups before the
majority of users get hit by them.
If the a majority (or even a significant minority of people, amongst whom
are a number who are unable to read bug reports and edit text files) of
end-users are using testing, we have a different problem - if you're not
capable of checking for and reading bug reports, then Branden's right, you
shouldn't be participating in the *testing* of something like a new release
of Debian.
Yes, it's annoying when you think you might have made a mistake, spend a
couple of hours trying to fix it, and then realise that it's a reported
bug with a documented fix. It happens to all of us. But it's our fault if
we don't check the bug reports first.
Suggestion: To make checking bug reports in testing easier, would it
be useful to have a simple way to get only bug reports for bugs which
seem to have "appeared" with the latest release in stable/testing/unstable
from the BTS?
The other problem that I hinted at above is the fact that too many users
feel that they have to move over to testing.
Given the way that Debian develops, if a user requires a new feature that's
only present in a testing package, they often^Wusually have to essentially
go the whole hog and upgrade their whole system to testing. I don't believe
that this is a desirable state of affairs (although with the advent of
testing it's certainly a whole load better than it used to be, where such
users were required to go all the way to unstable).
This appears to be largely due to the way shared library dependencies are
calculated, and the fact that most people seem to do development on
bleeding-edge systems.
Surely there must be some way that we can improve this situation - obviously
some packages will require major upgrades (like, it really won't work without
perl 5.6, or the latest libc or whatever), but I reckon a whole load would
work just fine if they'd been built on a stable system - as shown by the
number of private repositories of new-packages-built-for-potato that exist.
Thoughts? Ideas?
Cheers,
Nick
--
Nick Phillips -- nwp@lemon-computing.com
Ships are safe in harbor, but they were never meant to stay there.
Reply to: