Supported python versions, pre-commit tests, sphinx

Martin Pool mbp at canonical.com
Wed Jun 2 03:59:01 BST 2010


On 2 June 2010 09:28, Robert Collins <robertc at robertcollins.net> wrote:
> Currently we support python2.4 and up, and build optional docs via
> sphinx. sphinx seems to be nicer than what we were using before, and
> Ian wants to delete the old cruft:)
>
> However our pre-commit testing environment currently runs 'hardy', and
> that does not have python-sphinx available.
>
> We have a few of [easyish] options.
>  - don't make this change
>  - stop testing that the docs build
>  - backport sphinx to hardy
>  - change the test environment to run 'lucid'
>
> These have different tradeoffs.
> If we stop testing that docs build, we pretty much guarantee that
> errors will creep in.
>
> If we backport sphinx to hardy, we'll be able to commit test things,
> but we won't be able to *build bzr* on a normal hardy system (and
> hardy is still important to us, I think - its supported until 2011 on
> the desktop). But perhaps that doesn't matter, or perhaps we should
> start building docs as part of shipping a tarball, to reduce the
> dependencies end users need.
>
> If we change the test environment to run 'Lucid' we would no longer be
> checking python2.4 compatibility on every mainline commit - and I
> think that this is actually a pretty large risk.

Right now, I think we (perhaps you, Robert) should backport sphinx to
hardy, ideally by getting it into the official hardy-backports.  If it
turns out that's really hard because it has a large dependency chain,
then we can reconsider.

I don't think running PQM on 2.4 is critical.  Errors that break 2.4
but work on 2.6 do happen but are fairly rare and also fairly easy to
fix, compared to things that break on win32 for example.  I would be
ok with upgrading the PQM chroot to Lucid as long as we keep testing
hardy python2.4 within Babune.  I don't think it's worth initiating
this now just to get Sphinx working but if IS wanted to do it, I would
not object.

My impression is that a majority of doc build problems are only caught
when a human examines the results, so there is some value in doing it
from PQM but it doesn't absolutely have to be done there.

-- 
Martin <http://launchpad.net/~mbp/>



More information about the bazaar mailing list