Bug#856640: unblock: suricata/3.2.1-1
On 7 March 2017 at 22:50, Adam D. Barratt <adam@adam-barratt.org.uk> wrote:
> On Mon, 2017-03-06 at 19:06 +0100, Arturo Borrero Gonzalez wrote:
>> On 4 March 2017 at 14:26, Salvatore Bonaccorso <carnil@debian.org> wrote:
>> > Hi Adam,
>> >
>> > On Sat, Mar 04, 2017 at 11:56:23AM +0000, Adam D. Barratt wrote:
>> >> On Fri, 2017-03-03 at 10:55 +0100, Moritz Muehlenhoff wrote:
>> >> > Then it should not be in a stable release, but updated via stretch-updates.
>> >>
>> >> That's self-contradictory. -updates is a subset of proposed-updates, so
>> >> any packages released via it are necessarily in stable.
>> >
>> > Not Moritz here, but maybe we can argue that way: It could be handled
>> > like clamav (and be updated to upstream point updates via
>> > stretch-updates), or possibly suricata should not be at all in a
>> > stable release beeing to fast moving target[*].
>> >
>>
>> After some thinking, yes. Upstream point updates via stretch-updates
>> is probably the way to go.
>
> It's not a given, however; doing so is extra work for both us and you,
> and disruption for users, so we have to be sure that it's the best idea.
>
> In order to consider that, we'd need some more information, for example:
>
> - how often do upstream make point releases?
> - do they just include bug fixes, or also new features?
> - what severity of fixes are included?
> - what sort of testing (preferably automated) does the code get before
> release?
> - what level of regressions are generally experienced with new releases?
>
I contacted upstream and this is the reply:
==== 8< ====
> - how often do upstream make point releases?
We try to do no more than once per month. I think the current pattern is
more once per 2 months or so. For 3.1 it was:
refs/tags/suricata-3.1 Mon Jun 20 12:16:45 2016 +0200
refs/tags/suricata-3.1.1 Wed Jul 13 10:06:41 2016 +0200
refs/tags/suricata-3.1.2 Wed Sep 7 09:59:17 2016 +0200
refs/tags/suricata-3.1.3 Tue Nov 1 13:04:20 2016 +0100
refs/tags/suricata-3.1.4 Wed Feb 15 12:05:08 2017 +0100
> - do they just include bug fixes, or also new features?
Mostly bug fixes, but small features may sometimes creep in. We do make
sure they are not intrusive or breaking config, etc.
In the 3.1.x branch we see 2 releases that had feature additions:
https://redmine.openinfosecfoundation.org/versions/87
https://redmine.openinfosecfoundation.org/versions/88
None of them was intrusive.
> - what severity of fixes are included?
Pretty much all that don't require big rewrites. Critical/security
issues are most important and these trigger the release. But we'll
include minor fixes as well.
> - what sort of testing (preferably automated) does the code get before
> release?
Some overview
https://github.com/inliniac/suricata#overview-of-suricatas-qa-steps
There is lot of automated testing. We have an internal CI that is used
to find crashes, functional regressions, leaks, coding errors, etc. Our
'git master' is notoriously stable, as nothing gets merged before it
passed QA :)
> - what level of regressions are generally experienced with new releases?
For major release mostly performance regressions of very specific setups.
For minor releases I can't think of any pattern. I think the issues we
fix in minor releases have either been around for a long time or were
introduced in the last major release.
It's our policy to remain backwards compatibility with older rules and
configs, and point-releases will never introduce breaking changes.
==== 8< ====
regards
Reply to: