Guido van Rossum schrieb: > On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose <d...@ubuntu.com> wrote: >> Guido van Rossum schrieb: >>> I'm not sure I understand your request. Is it okay to build docs using >>> a version of sphinx that is included in the distro? Is there a >>> specific revision that you would like to see rolled back, or do you >>> have a specific fix in mind? >> the specific change was committed in r68428. I didn't check if reverting this >> causes regressions in building the docs. >> >> A safe approach would be to only use build dependencies on a branch which >> were >> released before the first release of the branch. I assume in this case, the >> branch should stick with sphinx-0.5 and not rely on newer sphinx versions (or >> sphinx dependencies which were released after the python-2.6.0 release). > > This seems rather restrictive. It would mean that if we found a bug in > sphinx-0.5 that was fixed later in sphinx development we couldn't > depend on the bug being fixed for the lifetime of Python 2.6, to > satisfy this requirement. Ditto for new sphinx features that might > make life easier for the doc authors, or in some cases enable new > types of markup that would clarify the docs. It would make backporting > doc-fixes from 2.7 harder too.
the rationale for this proposal is that when a Linux distribution does freeze for a release, only bug fixes are allowed during the freeze until the release. If you do consider a new release on the branch as a bug fix release which can be allowed during a freeze, but it depends on a new upstream release of it's build dependencies we still cannot include it because of the tightened build dependency. > I could live with "only depend on released versions of anything" but I > don't think I could live with "don't depend on anything released after > 2.6.0 was released" (which IIUC is what you are proposing here). I could live with a "don't depend on anything released after 2.6.0 was released, unless it is a bug fix release", e.g. allowing sphinx-0.5.x releases (assuming these don't have new features). I don't know of any other open source software which allows unlimited changes on the build requirements in this way on a release branch. Matthias >>> I suspect few people here understand the >>> (apparently largely political) ins and outs of the rules that guard >>> inclusion into Debian -- I certainly don't, and I don't have the time >>> to become an expert in them. So rather than trying to explain the >>> rules to us, could you make a specific suggestion of something we >>> could *do* to fix your problem? >> please see the proposals above. I'm not sure about the best approach how to >> make >> backporting to the branch as easy as possible. >> >> Matthias >> >>> --Guido >>> >>> On Sun, Jan 25, 2009 at 5:40 AM, Matthias Klose <d...@ubuntu.com> wrote: >>>> Hi, >>>> >>>> the requirement to build the documentation using a sphinx version from the >>>> trunk >>>> was merged to at least the 2.6 branch. This is clearly not a bug fix. Is it >>>> really necessary to rely on a trunk/unreleased version? Would it be >>>> possible to >>>> revert this change? >>>> >>>> Background: The Debian distribution requires distribution of files which >>>> can be >>>> edited in the preferred format, which excludes generated documentation. I >>>> can >>>> pre-build the 2.6 documentation, and then include it in the so called >>>> "contrib" >>>> section of the archive, but I would like to see it available in the "main" >>>> section. Including a copy of the sphinx trunk in the python package >>>> uploaded to >>>> the distribution would be a hack around this (it is unlikely that the >>>> sphinx >>>> trunk version will be available in Debian). >>>> >>>> For python-2.5, Debian was not able to put the docs in the "main" section, >>>> because a build tool with (in the eyes of Debian) "non-free" license was >>>> used to >>>> build the docs. It is nice that this is fixed now, but for now one reason >>>> is >>>> exchanged by another one why we cannot move the docs to Debian's "main" >>>> section >>>> of the archive. >> > > > _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
