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

[Matthias Klose]

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