Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 11:08:21PM +0000, Colin Watson wrote:
> On Tue, Mar 04, 2003 at 09:53:18PM +0000, Colin Watson wrote:
> > On Tue, Mar 04, 2003 at 04:11:02PM -0500, stan wrote:
> > > Well, then shouldn't it allow "stable" to be released often enough that it
> > > acn be used in production> For instance how old are the prel modules, and
> > > devlopment environment in it? Ancinet by modern standards.
> >
> > We're trying, damnit.
>
> Oh, also, it is far from obvious to me that perl 5.8.0 is yet stable
> enough for production use. For instance, its behaviour of interpreting
> input streams as UTF-8 in UTF-8 locales is being changed upstream in
> response to many bug reports (particularly from Red Hat 8.0 users, since
> that shipped with a UTF-8 locale as the default), and the new safe
> signals implementation has caused some problems which mean that the next
> upstream release will allow them to be turned off. I'm avoiding shipping
> anything later than perl 5.6.1 with our products at work, perl 5.6.1 is
> still formally supported, and it's a rare module that can't be built for
> it.
OK, I've not had any problems whatsover with the version of perk that's in
testing. Now I don't stress the internationalization issues, or the
threading issues. I was actully more refering to the latest perl modules,
which tend to have enhancements, and bug fixes failry often, rather than
per itslef.
>
> So I think your example nicely demonstrates that current is not stable,
> and that lightning-fast integration of brand new upstream releases into
> Debian stable is not necessarily what people using Debian in production
> actually need. Version numbers are not everything. If you want something
> newer for some specific case, then you've always got the source.
Perhpas not. But examples are just that. A means to point out a basic
issue. They are never perfect.
--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
Reply to: