I don't know of any examples of introducing *new* deps in stable branch updates, but there have been several occasions where version requirements were bumped higher to unblock gate issues. IMHO that can be worse for stable distros (as opposed to requiring a new dependency that most can provide)

That said, I'm heavily leaning toward -1 on this as well.  This isn't a new bug.  Concerns about the use of the use python-oauth2 in Keystone on LP go a while now and a decision was made to ship optional oauth support in Havana's using python-oauth2.  I don't think we can undo that now.  A better solution would be to add a big ugly warning to documentation referencing relevant CVEs and mentioning the issue is fixed in Icehouse.

I also don't think its unreasonable for distros to carry their own cherry-picked patch from Icehouse to address the issue.


On Mon, Mar 24, 2014 at 5:54 AM, Thierry Carrez <thierry@openstack.org> wrote:
See the discussion @ https://review.openstack.org/#/c/70750/

I think this is not an acceptable change for the stable branch. We
promise a "safe source of fixes", which means seamless upgrades that do
not require extra actions for followers of the stable branch. IMHO
replacing a library dependency by another library requires extra actions
to be taken on the deployer side (making sure you have the new
dependency packaged / present), so it's out of line.

Now I hear the pressure from the distributions which have already ripped
out oauth2 -- the change is indeed harmless and desirable for them. But
I still think we'd break our promise for a safe source of fixes to every
user of the stablebranch if we accepted that patch.

In that case it seems fair for distributions which want to replace
oauth2 with a safer alternative to carry a specific patch.

Thoughts ? Do we have past examples of introducing new deps in stable
branch updates ?

--
Thierry Carrez (ttx)

_______________________________________________
Openstack-stable-maint mailing list
Openstack-stable-maint@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint