build dependency on the branches on sphinx trunk necessary?
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.
Matthias
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? 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?
--Guido
On Sun, Jan 25, 2009 at 5:40 AM, Matthias Klose <doko@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.
Matthias
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
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).
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 <doko@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.
On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose <doko@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.
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 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 <doko@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.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum schrieb:
On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose <doko@ubuntu.com> wrote:
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?
Guido van Rossum schrieb: 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 <doko@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.
On Mon, Jan 26, 2009 at 1:59 PM, Matthias Klose <doko@ubuntu.com> wrote:
Guido van Rossum schrieb:
On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose <doko@ubuntu.com> wrote:
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?
Guido van Rossum schrieb: 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.
I would agree with you if it was for stuff that matters to the runtime environment. But IMO this strict requirement doesn't make sense for documentation in micro-releases -- changes to the documentation don't matter for the runtime backwards compatibility. AFAIK we also don't block performance improvements in micro-releases (though you'd have to ask a release manager for the exact policy).
Would it help if we started bundling the required version of sphinx with Python?
In general I expect that you're not going to get a lot of help with this issue, since it sounds like typical "business as usual" in the weird and wonderful world that is Debian politics, and we have limited patience for that. We're all volunteers here too, and we're not really looking for more work. If Debian wants to ship with an outdated version of Python, it is free to do so.
--Guido
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 <doko@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.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum schrieb:
On Mon, Jan 26, 2009 at 1:59 PM, Matthias Klose <doko@ubuntu.com> wrote:
On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose <doko@ubuntu.com> wrote:
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?
Guido van Rossum schrieb: 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.
Guido van Rossum schrieb: 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.
I would agree with you if it was for stuff that matters to the runtime environment. But IMO this strict requirement doesn't make sense for documentation in micro-releases -- changes to the documentation don't matter for the runtime backwards compatibility. AFAIK we also don't block performance improvements in micro-releases (though you'd have to ask a release manager for the exact policy).
Would it help if we started bundling the required version of sphinx with Python?
yes, it definitely would help, including the dependencies needed by sphinx.
In general I expect that you're not going to get a lot of help with this issue, since it sounds like typical "business as usual" in the weird and wonderful world that is Debian politics, and we have limited patience for that.
you may call it politics, I call it reproducabilty of the build with a set of requirements. the limitation on "runtime backwards compatibility" could allow changes of the test environment as well, which might introduce noise in the testsuite, having to investigate about a regression in the runtime or the testsuite. I do see your point, but from the Debian point of view I do disagree.
We're all volunteers here too, and we're not really looking for more work. If Debian wants to ship with an outdated version of Python, it is free to do so.
your conclusion is wrong. Debian does want to ship with the most recent Python version released before a Debian freeze.
Matthias
--Guido
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 <doko@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.
On Mon, Jan 26, 2009 at 2:26 PM, Matthias Klose <doko@debian.org> wrote:
Guido van Rossum schrieb:
On Mon, Jan 26, 2009 at 1:59 PM, Matthias Klose <doko@ubuntu.com> wrote:
On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose <doko@ubuntu.com> wrote:
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?
Guido van Rossum schrieb: 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.
Guido van Rossum schrieb: 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.
I would agree with you if it was for stuff that matters to the runtime environment. But IMO this strict requirement doesn't make sense for documentation in micro-releases -- changes to the documentation don't matter for the runtime backwards compatibility. AFAIK we also don't block performance improvements in micro-releases (though you'd have to ask a release manager for the exact policy).
Would it help if we started bundling the required version of sphinx with Python?
yes, it definitely would help, including the dependencies needed by sphinx.
Let's see if Georg has any comments on that.
In general I expect that you're not going to get a lot of help with this issue, since it sounds like typical "business as usual" in the weird and wonderful world that is Debian politics, and we have limited patience for that.
you may call it politics, I call it reproducabilty of the build with a set of requirements. the limitation on "runtime backwards compatibility" could allow changes of the test environment as well, which might introduce noise in the testsuite, having to investigate about a regression in the runtime or the testsuite. I do see your point, but from the Debian point of view I do disagree.
Too bad.
We're all volunteers here too, and we're not really looking for more work. If Debian wants to ship with an outdated version of Python, it is free to do so.
your conclusion is wrong. Debian does want to ship with the most recent Python version released before a Debian freeze.
What conclusion? My use of "if" clearly indicated that I was speaking hypothetically.
Matthias
--Guido
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 <doko@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.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, Jan 26, 2009 at 1:59 PM, Matthias Klose <doko@ubuntu.com> wrote:
On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose <doko@ubuntu.com> wrote:
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?
Guido van Rossum schrieb: the specific change was committed in r68428. I didn't check if reverting
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,
Guido van Rossum schrieb: this 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.
Chances are very high that if you grab a copy of sphinx from svn on the date of the python X.Y release in question that the docs for any updates to that .Y release will always build using that sphinx. If not, its up to you as the interested party to fix/patch them. I doubt that'll be much work.
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.
As a developer I don't consider the documentation to be a critical part of the build since it isn't strictly tied to a particular release of python, afaict they're only -guaranteed- to build using a sphinx available at the time of any given release because that is what was used to make the release. Nothing else.
Bundling the required version of sphinx with future Python releases as Guido suggests is not a bad idea.
If you want to pick a sphinx version to use with a particular python build, find the date of the release tag for that python version and sync to sphinx at that date. It'll be up to you (debian package maintainers) to make sure that the docs keep building with that version of sphinx within that release branch. That could involve patches if someone commits something that breaks your assumption. But lets be realistic: documentation changes post-release are rare. It won't be much, if any, work for the debian package maintainer.
-Greg
Matthias Klose schrieb:
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.
It doesn't; I've successfully built the docs with Sphinx 0.5.1+ after reintroducing the try/except guards, so I've committed that as r68984.
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).
Since I can't guarantee that everyone will keep to 0.5 compatibility, it would be great if you could feel responsible for checking that it is still given from time to time.
Georg
participants (5)
-
Georg Brandl -
Gregory P. Smith -
Guido van Rossum -
Matthias Klose -
Matthias Klose