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

[Guido van Rossum]

On Mon, Jan 26, 2009 at 2:26 PM, Matthias Klose <doko at debian.org> wrote:
> 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.

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



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)