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

[Guido van Rossum]

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?

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

--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/)