On Mon, Jan 26, 2009 at 2:26 PM, Matthias Klose <d...@debian.org> wrote: > Guido van Rossum schrieb: >> On Mon, Jan 26, 2009 at 1:59 PM, Matthias Klose <d...@ubuntu.com> wrote: >>> 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. >> >> 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 <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. >>>> >>>> >>> >> >> >> > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
