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. > 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 <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
