Subject: Re: [boost] Security bugs policy
From: Lars Viklund (zao_at_[hidden])
Date: 2012-12-22 18:27:04
On Sat, Dec 22, 2012 at 01:15:12PM -0800, Artyom Beilis wrote:
> I would like to know if there is any policy about security bug fixes, updates or releases.
Nope. There's no distinction at all between security fixes, bug fixes
and new features.
> - Do we have any policy about it?
Current development has only one development direction, and it's:
* releases are made by pulling in stuff from the wild west trunk;
* point releases (1.NN.1+) are only made when there's something very
important that needs to be fixed immediately but is found after the
release window is closed, and someone can convince the release
wranglers that it indeed is important enough to roll a point release
for instead of waiting for the next proper release.
> - If not we probably need one including backporting of security bug fixes to stable releases.
There is no such policy, and I've lifted this issue in the past on the
lists with very little response.
> What brings me to other issues...
> Should Boost support older releases with critical bug fixes/security bug fixes?
> For how long time?
In the current approach, I don't really see how this could easily be
It's definitely something that should be strongly considered for the new
modularised fancy-pants Ryppl-filled future.
Many other projects have a policy along the lines of:
* point releases get all applicable bugfixes,
* proper releases get features,
* releases have a lifespan of N months.
It's more work if you're not careful about separating bugfixes and
features, but in the long run, it does wonders for end user trust.
As for distros backporting unofficial fixes, all that'll do is fragment
the userbase, as they can't really rely on or determine what shenanigans
have been inflicted on a legacy version. If there is to be changes made
to older versions, it needs central coordination and a proper testable
-- Lars Viklund | zao_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk