Hello Thierry and Team,

Thanks for taking a little more time to explain. Nonetheless, perhaps
the most important point is still missing from your answer. Please see
below.

Le dimanche 18 janvier 2009 à 17:28 +0000, Thierry Carrez a écrit :

> > It makes it look like Ubuntu LTS is not even striving for
> > production-ready status and that this claim as well as that of "Long
> > Term" is but a slogan.
> 
> You seem to imply that quality and production-ready standards imply
> providing updates that add functionality to an already released product.

Well, definitely not, please read on.

> That is really not the case.

Agreed.

>  The idea is rather to try to fix existing
> bugs while ensuring the largest stability for the current users of the
> stable release. Introducing, "for human consideration"

Part of Ubuntu's motto. ;-)

> , new
> functionality into a stable release is wrong: you face the risk of a
> regression

which is the part of my former posts you seem to insist on missing. I
may indeed not be aware of such a regression, but :
    - there is no report of this alleged regression, wherever.
    - Ubuntu packagers would know, if I'm correct, since packages for
dnsmasq 2.46 were built for both Intrepid and Jaunty, and the
maintainers also patched the Hardy version as soon as a security flaw
was discovered.
So why not give the actual technical reason? Please do.

>  (even if very unlikely) for the majority of users to please a
> minority of them.

I fail to understand what minority you are referring to. Provided that a
post would represent a number of users (on top of the poster himself),
please add up the many posts I mentioned before and do the math ; while
this may not be the majority, we are definitely not talking about just a
few.

Trying to make such a point also misses on the issue of the targeted
audience. Some customers will simply not use Bind, or any other "easier"
DNS server than dnsmasq.
Hence, there is probably no such thing as a general DNS server users'
target audience, and figures should be evaluated accordingly.

As a real-world example, we actually had to switch two production
servers to Slackware because the site manager would more easily trust
both the security advisories he can find on the web and their need for
CNAME functionality than the package we backported (sadly); following
this (and other issues) , we have ceased to recommend Hardy as a
solution for security-conscious sites that cannot dedicate more
resources to IT management; although setting up the Slackware "model
server" was some task, it has already proved not to lead to such dead
ends, thus allowing us to revert our remote maintenance time budget to
normal. Please note that this had quite an impact in terms of Ubuntu's
image for most of this company's employees.


>  That's what upgrading is for : getting new
> functionality and bleeding-edge releases of software.

In upgrading to a _stable_ release?
If "recent" was the word, we'd be using Intrepid or Jaunty, and not the
self proclaimed production server that came out before we started our
projects. We would not use the production-ready-LTS argument on our
customers either.

Also, referring to _new_ functionality here feels odd ; CNAMEs may be
new to dnsmasq (making the product indeed ready for adoption in
different environments), they are not to DNS.
Once again, we are not discussing just some gizmo, but essential DNS
functionality, no matter how recently it may have been introduced in
dnsmasq.
We do understand the _fear_ of regression due to this function's novelty
_in_dnsqmasq_, but again there have been no reports of such a
regression, no matter where we look.

>  RHEL for example
> apparently still ships dnsmasq-2.39...

Slackware, ArchLinux, Debian's Lenny (currently "frozen") and OpenSuse
to name just a few all ship 2.46, which is even available in the
commercial version of the latter.
Besides, the comparison with RHEL seems inappropriate, since it is a
commercial product, and neither ourselves or our customers are part of
their partners ; it seems that companies like Ubuntu claim to offer the
same quality (a production-ready server OS) for free.

> 
> That said we understand the need to provide new functionality for users
> of the stable release and that's what the Backports project proposes.

And we all have yet to receive an answer from them... and by now it
would seem that more time was spent on either end discussing whether the
update is worthwhile than would be required to at least build the
package, if not test its integration within hardy for this hypothetical
(AFAIK) regression.

Finally, our operations are now fine here, some without Ubuntu, some
with our own backport, but we are still expecting a technical,
fact-based explanation to marking this bug as invalid. Your next answer
will help in determining whether it is still worthwhile looking into
Ubuntu's evolutions and support or if we should build up on different
solutions.

> 

Thanks again for your time,

Best regards,

Dr. Moe