You must have an exception. You probably want to answer the standard questions to make this go faster. I'm also wondering why python-sphinx is a blocker here... it's generally only used for building documentation. (OTOH, shiboken helps with creating language bindings so there could be some correlation here I just would like to know what it is.)

Replying to [comment:1 toshio]:

You must have an exception. You probably want to answer the standard questions to make this go faster. I'm also wondering why python-sphinx is a blocker here... it's generally only used for building documentation.

Shiboken documentation uses sphinx.ext.refcounting extension that has been dropped in Sphinx 1.2. See https://bugreports.qt-project.org/browse/PYSIDE-221

Most of the standard questions were answered above, formal way is here:

• Q: Has the library behaviour been modified? A: Yes, to fix build issues.
• Q: Why haven't the changes been pushed to the upstream library? A: Bundled code is now upstream
• Q: Could we make the forked version the canonical version within Fedora? A: We could, but shiboken is the only consumer
• Q: Are the changes useful to consumers other than the bundling application? A: No, shiboken is the only consumer of these libraries and upstream continues development only in the bunded code, not the standalone projects
• Q: Is upstream keeping the base library updated or are they continuously one or more versions behind the latest upstream release? A: Bundled libraries are now where upstream development happens
• Q: What is the attitude of upstream towards bundling? A: As there were no other consumers of standalone libraries, upstream decided to work only on bundled code and actually merge it to the codebase
• Q: Overview of the security ramifications of bundling A: Original upstream is unmaintained, as the only development happens on in-tree bundled code, it actually leads to higher security, it would be hard to sync all changes to our own forked versions
• Q: Does the maintainer of the Fedora package of the library being bundled have any comments about this? A: The same maintainer - me, and as I proposed to go only with bundled code, no additional comments.
• Q: Is there a plan for unbundling the library at a later time? A: No, upstream development happens in-tree of shiboken
• Q: Please include any relevant documentation

pyside IRC channel

[15:13] <jreznik> and another question - is apiextractor and generatorrunner dead and bundled code is used in shiboken (so fixed for sphinx update?)
[15:15] <OdyX> yes

GIT repos as an evidence https://qt.gitorious.org/pyside/ - see fixes going only to shiboken + http://qt-project.org/wiki/PySide

So I ask formally to grant an exception to bundle apiextractor and generatorrunner in shiboken code as it's now the canonical upstream in-tree code.

From information in your comment and some further clarification from rdieter it seems like the apiextractor/generatorrunner devs have merged their code into the shiboken tree rather the devs of those projects disappeared and the shiboken devs decided to bundle the code into their tree. That would be justification to approve this for us. Other factors that we discussed were that apiextractor and generatorrunner seem to just be used at build time and that no one else uses it.

So far voting in the meeting we only had four people to vote. Voting so far:

• +1: geppetto, abadger1999, RemiFedora, SmootherFrOgZ
• 0: 0
• -1: 0
• Need one more +1 from tibbs, spot, Rathan, limburgher, or racor

+1 from me.