[python-committers] build dependency on the branches on sphinx trunk necessary?

[Matthias Klose]

Guido van Rossum schrieb:
> On Mon, Jan 26, 2009 at 1:27 PM, Matthias Klose <doko at 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 <doko at 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.
>>
> 
> 
>