[Dnsmasq-discuss] [dnsmasq] Errors found by static analysis of source code (Coverity)

Simon Kelley simon at thekelleys.org.uk
Thu Feb 7 16:23:08 GMT 2013


On 07/02/13 15:59, Tomas Hozza wrote:
> ----- Original Message -----
>> I'm open to comments about the dnsmasq release process. Would people
>> prefer more/less frequent releases?
> 
> Maybe some "stable" amount of time between stable releases would be good.
> Maybe half a year of so (maybe less or more).

There have been 13 releases in the last three years, so we're not far
off that. Remove the releases which came out after a week or two to fix
show-stopping bugs, and  once every six months is about what we're
doing. It would be good to avoid "stable" releases with show-stopper
bugs though.
> 
>> A different sequence to the test->rc->release currently used.
> 
> This is completely fine.
> 
Except that it isn't finding showstoppers every few releases.......

>> Stable and development streams?
> 
> I think stable and development stream would make sense. Having at least
> one (maybe two) stable supported version with bug fixes without adding
> any new features. And then one development stream for any new features.
> Stable release (test->rc->release) would be branched from development
> branch and then tested and stabilised. We use similar approach in Fedora
> and it works pretty good.

It would be good to do that, I'm not sure if it would be worth the
effort, Backwards compatibility  in dnsmasq is high, so there's not
normally a reason not to fix bugs just by moving to the newest release.
On the other hand, it's psychologically  easier, and it avoid the
possibility of getting a brown-paper-bag release in the first week it's out.

> 
> I have one extra question. Have you ever though about having some TEST
> suite for dnsmasq?

A regression test suite would be fantastic. If I every get time, I'll do
it right after better documentation :-)

> I can imagine something similar like Nmap's Ncat have.
> It's basically a Perl script that provides some basic framework for tests.
> So if there is any new feature added or something fixed, also some test
> can be added. I would provide a way to check if any new fix/feature did
> break anything. It would also allow dnsmasq users to implement tests for
> their own use cases. Also requiring a test for new features would be great.
> So the developer is required to write a test for his own feature.
> 
> Tests would also enable older (not supported) versions of dnsmasq to be
> tested in case of backporting some fixes from current version.
> 
> Would you be interested in something like this?
> 

Certainly would.



Cheers,

Simon.

> Regards,
> 
> Tomas Hozza
> 




More information about the Dnsmasq-discuss mailing list