On Sep 11, 2017, at 3:42 AM, Martin Pauly <pauly@hrz.uni-marburg.de> wrote:
I'm afraid you got me a bit wrong here.
That was more of a general rant against bad practice, and not against you in particular.
I have understood that the Debian approach is basically broken from the main developer's view (didn't really know it this bad before this discussion, though). I am not asking for "distribution pampering" here. I am asking for a seperation of security-relevant fixes from functional changes in the official releases.
The security fixes are all broken out in git, as patches.
Actually, the 3.0.15 release already comes pretty close to this. From the release notes I read 4 feature improvements, but 26 bugfixes, at least 15 of which are security-relevant. So if you had funneled the bugfixes into some extra release, it would not have made much of a difference, right?
We only have so much time in a day. If you're willing to pull all of the security fixes back into 3.0.14, 3.0.13, 3.0.12, etc, that would be nice.
So far, so good. But immediately the question arises what to to with older versions. There will always be people asking for a security-only release for their old version. So even if you adopted this idea, you would have to impose a practical limit. In the simplest form, you could do it only for the current version. In practice I would suggest going back to some point _you_ decide, e.g. 3.0.12 in this example.
Feel free to do so.
Why would this help? There's quite a number of people out there who run FR with very limited resources,
Like me, and the other developers.
especially when it comes to software and network skills. Like it or not, this is reality. Many IT departments are understaffed or underfunded or both. On the other hand, most installations use only a very limited subset of FR's huge functionality. So once you'vo got it to do what you need, you want to change as little as possible to address a particular security issue. Other functional improvements can easily be postponed, security fixes cannot in general.
That's all nice. But... it involves *me* doing more work because other people don't want to do more work. Which isn't a very appealing request. Alan DeKok.