Please update dnsmasq hardy packages to version 2.46

Redirecting to hardy-backports... Please see https://help.ubuntu.com/community/UbuntuBackports for more information on the backport process.

Hi Thierry,

Thanks for forwarding. Looking forward to the backporters' response.

_Yet_, can you tell me if v2.46 stands a chance of making it to the
regular LTS repos ?

I must stress again that this would be an important improvement for LTS.

To summarize:
    - if any dnsmasq user wants / needs to use a cname directive, v2.46
is required.
    - the question was asked several times in the past in every ubuntu
forum whose language I can read (many times, that is...)
    - beginners won't backport
    - more experienced users may find it a waste of time to backport,
and their work may not benefit to the community (I just backported,
clumsily, and would not submit this work for anybody else's use unless
someone officially in charge would take the time to validate / improve
this backport).
     - anyone not directly involved in Ubuntu will not want to backport
every single daemon in order to stick to the LTS release (I have
backported 3 different servers last month, and this is not my idea of a
Xmas holiday ;-).
    - LBNL who'd want the hassle of installing and configuring bind
solely in order to declare a CNAME (or any number of them)? (or any
other DNS server 4 that matter...)

I probably should not have mentioned the backports repo in my previous
message ; getting v2.46 there would surely be better than not at all on
Hardy, _nonetheless_ the whole point should be to give _regular_ Hardy a
simple DNS server with every function anyone would expect which works
_out_of_the_box.

So please let me know if inclusion in the main Hardy repos could be
considered at all (there may be something I missed here...)

Regards,

Dr. Moe

Le lundi 05 janvier 2009 à 19:37 +0000, Thierry Carrez a écrit :

> Redirecting to hardy-backports... Please see
> https://help.ubuntu.com/community/UbuntuBackports for more information
> on the backport process.
>
> ** Also affects: hardy-backports
> Importance: Undecided
> Status: New
>
> ** Changed in: dnsmasq (Ubuntu)
> Status: New => Invalid
>

On Mon, Jan 05, 2009 at 09:45:38PM -0000, dr.moe wrote:
> _Yet_, can you tell me if v2.46 stands a chance of making it to the
> regular LTS repos ?
>
> So please let me know if inclusion in the main Hardy repos could be
> considered at all (there may be something I missed here...)
>

I don't think so. Criteria for making Stable Release Updates are
outlined on the following wiki page:

https://wiki.ubuntu.com/StableReleaseUpdates

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

Hello Mathias and Team,

After carefully reading the page you mention, I still fail to
understand why dnsmasq 2.46 should not make its way to Hardy LTS at all.

Since :
    - It IS also a security upgrade (should be raised above hardy's
current version according to upstream's site).
    - No regression was introduced, as other distros have acknowledged,
as your competitors' package listings show.

The only 'valid' reason mentioned on this policy page would be : "bugs
that (a) are Fix Released in the current development release and (b)
have been nominated but not approved for stable releases"...
although it remains unclear what exact policy applies in these cases.

Moreover, this update would seem to qualify as a MicroException, in
Ubuntu's own terms, provided the packagers actually can communicate with
one another, which seems to be very much the case.

All in all, what a disappointing answer! Not even a remote chance,
either now or later!
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.

Moreover, such a brisk invalidation of an otherwise valid report without
even bothering to examine or answer the other arguments we gave
regarding the benefits this update could bring to Ubuntu gives your
company a bad name.
Not to mention referring us to your policy page, since software quality
and marketing have little to do with one another.

It had been a hard time convincing several of our customers to switch to
Ubuntu, and there will be no way for me or anyone else to talk them into
accepting quick and dirty handmade non-supported backports like the one
I made for this daemon and am currently using.
Alas, the management's conclusions will likely highly resemble mine
above: not production-ready, not an LTS release but for the name.
(Please note this is not the first issue of this kind we've come across,
only the first one reported, and that it used to seem - from testing
previous releases since the not-production-ready-either dapper drake -
that Ubuntu's maintainers were among the most reactive).

Still hoping at the very least for an officially supported backport...

And at best for more sensible consideration, i.e. a detailed answer to
the reasons we formerly gave for this request, which ideally would match
Ubuntu's claims to quality.

Meanwhile (if so) I remain terribly sorry for this lack of concern
towards quality and human consideration.

Regards,

Dr. Moe

"In a democratic community, nagging may seem an appropriate response to
contempt." Rvd. J. Barley

Le mardi 06 janvier 2009 à 15:44 +0000, Mathias Gug a écrit :

> On Mon, Jan 05, 2009 at 09:45:38PM -0000, dr.moe wrote:
> > _Yet_, can you tell me if v2.46 stands a chance of making it to the
> > regular LTS repos ?
> >
> > So please let me know if inclusion in the main Hardy repos could be
> > considered at all (there may be something I missed here...)
> >
>
> I don't think so. Criteria for making Stable Release Updates are
> outlined on the following wiki page:
>
> https://wiki.ubuntu.com/StableReleaseUpdates
>
> --
> Mathias Gug
> Ubuntu Developer http://www.ubuntu.com
>

Hi Thierry,...

> 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. That is really not the case. 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", new functionality into a stable release is wrong: you face the risk of a regression (even if very unlikely) for the majority of users to please a minority of them. That's what upgrading is for : getting new functionality and bleeding-edge releases of software. RHEL for example apparently still ships dnsmasq-2.39...

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

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_ f...