Hi Arturo, >> 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.
Cool, thanks. > 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 repo. Cheers Sascha
