On Thu, 2018-04-26 at 15:49 +0100, Stephen Finucane wrote:
> On Wed, 2018-04-25 at 12:06 -0500, Sean McGinnis wrote:
> > > > >
> > > > > [1] https://review.openstack.org/#/c/564232/
> > > > >
> > > >
> > > > The only concern I have is that it may slow the transition to the
> > > > python 3 versi
On Wed, 2018-04-25 at 12:06 -0500, Sean McGinnis wrote:
> > > >
> > > > [1] https://review.openstack.org/#/c/564232/
> > > >
> > >
> > > The only concern I have is that it may slow the transition to the
> > > python 3 version of the jobs, since someone would have to actually
> > > fix the warnin
On 2018-04-25 13:10:42 -0400 (-0400), Doug Hellmann wrote:
[...]
> Transitioning jobs is a bit painful because the job definitions and
> job templates are defined in separately places. If we don't want
> this setting to be controlled from a file within the git repo, I
> guess the most expedient thi
Excerpts from Sean McGinnis's message of 2018-04-25 11:55:43 -0500:
> > >
> > > [1] https://review.openstack.org/#/c/564232/
> > >
> >
> > The only concern I have is that it may slow the transition to the
> > python 3 version of the jobs, since someone would have to actually
> > fix the warnings
> >>
> >>[1] https://review.openstack.org/#/c/564232/
> >>
> >
> >The only concern I have is that it may slow the transition to the
> >python 3 version of the jobs, since someone would have to actually
> >fix the warnings before they could add the new job. I'm not sure I
> >want to couple the tasks
On 25/04/18 11:41, Doug Hellmann wrote:
Excerpts from Sean McGinnis's message of 2018-04-25 09:59:13 -0500:
I'd be more in favour of changing the zuul job to build with the '-W'
flag. To be honest, there is no good reason to not have this flag
enabled. I'm not sure that will be a popular opinio
> >
> > [1] https://review.openstack.org/#/c/564232/
> >
>
> The only concern I have is that it may slow the transition to the
> python 3 version of the jobs, since someone would have to actually
> fix the warnings before they could add the new job. I'm not sure I
> want to couple the tasks of f
Excerpts from Sean McGinnis's message of 2018-04-25 09:59:13 -0500:
> > > > >
> > > > > I'd be more in favour of changing the zuul job to build with the '-W'
> > > > > flag. To be honest, there is no good reason to not have this flag
> > > > > enabled. I'm not sure that will be a popular opinion t
> > > >
> > > > I'd be more in favour of changing the zuul job to build with the '-W'
> > > > flag. To be honest, there is no good reason to not have this flag
> > > > enabled. I'm not sure that will be a popular opinion though as it may
> > > > break some projects' builds (correctly, but still).
On Fri, 06 Apr 2018 15:52:46 +0100
Stephen Finucane wrote:
> On Fri, 2018-04-06 at 08:02 -0500, Sean McGinnis wrote:
> > > >
> > > > How can we enable warning_is_error in the gate with the new PTI? It's
> > > > easy enough to add the -W flag in tox.ini for local builds, but as you
> > > > say
On Fri, 2018-04-06 at 08:02 -0500, Sean McGinnis wrote:
> > >
> > > How can we enable warning_is_error in the gate with the new PTI? It's
> > > easy enough to add the -W flag in tox.ini for local builds, but as you
> > > say the tox job is never called in the gate. In the gate zuul checks for
>
> >
> > How can we enable warning_is_error in the gate with the new PTI? It's
> > easy enough to add the -W flag in tox.ini for local builds, but as you
> > say the tox job is never called in the gate. In the gate zuul checks for
> > it in the [build_sphinx] section of setup.cfg:
> >
> > https
On Thu, 2018-04-05 at 16:36 -0400, Zane Bitter wrote:
> On 21/03/18 06:49, Stephen Finucane wrote:
> > As noted by Monty in a prior openstack-dev post [2], some projects rely
> > on a pbr extension to the 'build_sphinx' setuptools command which can
> > automatically run the 'sphinx-apidoc' tool bef
On 21/03/18 06:49, Stephen Finucane wrote:
As noted by Monty in a prior openstack-dev post [2], some projects rely
on a pbr extension to the 'build_sphinx' setuptools command which can
automatically run the 'sphinx-apidoc' tool before building docs. This
is enabled by configuring some settings in
>
> tl;dr: You don't _have_ to automate this stuff, but it helps.
>
> sphinx-apidoc generates stub files containing a whole load of autodoc
> directives. As noted above, you can check the output of a sphinx-apidoc
> run and you'll see just this. If I were to guess, Cinder simply checked
> in the
On Thu, 2018-03-29 at 07:47 -0500, Sean McGinnis wrote:
> > >
> > > It's not mentioned here, but I discovered today that Cinder is using the
> > > sphinx.ext.autodoc module. Is there any issue with using this?
> > >
> >
> > Nope - sphinx-apidoc and the likes use autodoc under the hood. You can
>
> >
> > It's not mentioned here, but I discovered today that Cinder is using the
> > sphinx.ext.autodoc module. Is there any issue with using this?
> >
>
> Nope - sphinx-apidoc and the likes use autodoc under the hood. You can
> see this by checking the output in 'contributor/api' or the likes.
On Wed, 2018-03-28 at 14:14 -0500, Sean McGinnis wrote:
> On Thu, Mar 22, 2018 at 10:43:45AM +, Stephen Finucane wrote:
> > On Wed, 2018-03-21 at 09:57 -0500, Sean McGinnis wrote:
> > > On Wed, Mar 21, 2018 at 10:49:02AM +, Stephen Finucane wrote:
> > > > tl;dr: Make sure you stop using pbr
On Thu, Mar 22, 2018 at 10:43:45AM +, Stephen Finucane wrote:
> On Wed, 2018-03-21 at 09:57 -0500, Sean McGinnis wrote:
> > On Wed, Mar 21, 2018 at 10:49:02AM +, Stephen Finucane wrote:
> > > tl;dr: Make sure you stop using pbr's autodoc feature before converting
> > > them to the new PTI f
Excerpts from Stephen Finucane's message of 2018-03-23 17:25:42 +:
> On Fri, 2018-03-23 at 12:23 -0400, Doug Hellmann wrote:
> > Excerpts from Monty Taylor's message of 2018-03-23 08:03:22 -0500:
> > > On 03/22/2018 05:43 AM, Stephen Finucane wrote:
> > > >
> > > > That's unfortunate. What we
On Fri, 2018-03-23 at 12:23 -0400, Doug Hellmann wrote:
> Excerpts from Monty Taylor's message of 2018-03-23 08:03:22 -0500:
> > On 03/22/2018 05:43 AM, Stephen Finucane wrote:
> > >
> > > That's unfortunate. What we really need is a migration path from the
> > > 'pbr' way of doing things to somet
Excerpts from Monty Taylor's message of 2018-03-23 08:03:22 -0500:
> On 03/22/2018 05:43 AM, Stephen Finucane wrote:
> >
> > That's unfortunate. What we really need is a migration path from the
> > 'pbr' way of doing things to something else. I see three possible
> > avenues at this point in time:
On 03/22/2018 05:43 AM, Stephen Finucane wrote:
On Wed, 2018-03-21 at 09:57 -0500, Sean McGinnis wrote:
On Wed, Mar 21, 2018 at 10:49:02AM +, Stephen Finucane wrote:
tl;dr: Make sure you stop using pbr's autodoc feature before converting
them to the new PTI for docs.
[snip]
I've gone thro
On 03/22/2018 04:39 PM, Sean McGinnis wrote:
That's unfortunate. What we really need is a migration path from the
'pbr' way of doing things to something else. I see three possible
avenues at this point in time:
1. Start using 'sphinx.ext.autosummary'. Apparently this can do similar
t
> >
> > That's unfortunate. What we really need is a migration path from the
> > 'pbr' way of doing things to something else. I see three possible
> > avenues at this point in time:
> >
> >1. Start using 'sphinx.ext.autosummary'. Apparently this can do similar
> > things to 'sphinx-apid
> >
> > Unfortunately this will not work to just revert the changes. That may fix
> > things locally, but they will not pass in gate by going back to the old way.
> >
> > Any cases of this will have to actually be updated to not use the
> > unsupported
> > pieces you point out. But the doc build
On Wed, 2018-03-21 at 09:57 -0500, Sean McGinnis wrote:
> On Wed, Mar 21, 2018 at 10:49:02AM +, Stephen Finucane wrote:
> > tl;dr: Make sure you stop using pbr's autodoc feature before converting
> > them to the new PTI for docs.
> >
> > [snip]
> >
> > I've gone through and proposed a couple
On Wed, Mar 21, 2018 at 10:49:02AM +, Stephen Finucane wrote:
> tl;dr: Make sure you stop using pbr's autodoc feature before converting
> them to the new PTI for docs.
>
> [snip]
>
> I've gone through and proposed a couple of reverts to fix projects
> we've already broken. However, going forw
tl;dr: Make sure you stop using pbr's autodoc feature before converting
them to the new PTI for docs.
There have been a lot of patches converting projects to use the new
Project Testing Interface for building docs [1]. Generally, these make
the following changes:
1. Move any requirements for b
29 matches
Mail list logo