On 19-05-13 18:22:35, Doug Hellmann wrote:
Dirk Müller <dirk@dmllr.de> writes:
Jeremy wrote:
It's still unclear to me why we're doing this at all. Our stable constraints lists are supposed to be a snapshot in time from when we released, modulo stable point release updates of the libraries we're maintaining. Agreeing to bump random dependencies on stable branches because of security vulnerabilities in them is a slippery slope toward our users expecting the project to be on top of vulnerability announcements for every one of the ~600 packages in our constraints list.
I think this is combining two different viewpoints in one: "snapshot in time" and "user expects it to be updated asap on security vulnerabilities". We are already updating upper-constraints on bugfixes for projects that openstack maintains, and we do so similarly for security fixes for packages that are part of openstack. Also, distribution vendor provided (non-pip installed bindeps) are maintained and updated by security fixes.
But our motivation for updating the list when *we* release a package is that we want to test that package with the rest of our code. That's consistent with the original purpose of the list, which was to control which things we run in CI so we can have more control over when releases "break" us, and it isn't related to the reason for the releases.
yep, we are FIRST concerned with stability, and possibly secondly concerned with security (as a project). This would be expanding our perview a ton (talking with fungi earlier, it'd add a bunch conplexity even if done in a basic way). At the moment this merge is on hold til we figure out if we want to do this, and if so, how (and would the cost be worth it). -- Matthew Thode