>> Yes, I see your point and agree that having 3.2 in testing in time for
>> the freeze is a priority. What do you think about the following course
>> of action: get 3.2 into testing now, and after the (soft? full?) stretch
>> freeze we upload a split-hyperscan package for the version that is
>> current at that time?
> Just uploaded 3.2-1 to unstable.
> With the freezes to come, migration to testing will be more
> complicated until the release.
> Perhaps the sensible way to go is to wait until the Stretch release to
> introduce the change.
> If a RC bug happens in testing during the freeze, we should be able to
> quickly fix it in unstable with no additional changes.
> Otherwise the package may be dropped from stretch/testing.
> We must avoid this extreme situation.
True. Let's be conservative then and wait.
>> I will keep the split-hyperscan versions up-to-date with the official
>> state of unstable/jessie-backports anyway (to be used internally by my
>> organization). So I wouldn't expect the final effort to introduce the
>> split package into Debian to be too bad.
> Do you have commit access to the pkg-suricata git repo?
> If so, you could push a branch there.
I don't think I have access. pkg-suricata seems to be an Alioth project
in its own right, and I'm not a member of its scm_* group.
> Beware that your current branch contains a lot of changes we don't
> need (ie, cleanups of your own commits).
> Please, push only the changes we are talking about (may require you to
> manually merge some commits before pushing to pkg-suricata)
> If you want, I can myself migrate the changes form your repo to pkg-suricata.
Oh, I was definitely going to massage the history a little bit to look
like less of an odyssey ;) I aim at just a handful of sensible commits
right on top of the current master HEAD.
Let me just prepare a clean final 'hyperscan' branch in my own repo and
then we can discuss what to do with it w.r.t. the official pkg-suricata