Open Stack

On 02/28/2016 01:18 AM, Davanum Srinivas wrote:
> Thomas,
> 
> Please try and let use know what kind of problems you see in Debian as
> projects have already switched to reno.

Dims,

Unfortunately, if I wrote about this, that's because I tried, and
experienced not very nice things packaging Mitaka b1 and b2. I sometimes
had to patch out the reno sphinx module to be able to build the sphinx
docs of some packages. For example:

http://anonscm.debian.org/cgit/openstack/python-os-client-config.git/tree/debian/patches/remove-the-use-of-reno.patch?h=debian/mitaka

I don't think the above patch is the way to go, because:
- We should address this in a more general way, not on individual
(Debian) packages
- Running "sphinx-build" should always work, no mater what
- The release notes also belongs in a Debian package

I already wrote about it to Doug. I opened a general topic about not
using git (and more specifically in this case: "git log") when
generating the documentation (see below the reference to the thread).
But it's looking like that's still not enough. :(

> I believe Thomas is referring to:
>
>     https://bugs.launchpad.net/reno/+bug/1520096

The funny part about this bug is that it was opened against Reno, which
by design, is doing things wrongly. Then the issue was kind of turned
around, and fixed in python-neutronclient. However, many other packages
have the problem too, and I don't believe that they will somehow all be
magically fixed and understand what should be done or not.

To me, the issue should really be fixed into Reno itself (if it is even
fixable...).

By the way, this bug was opened in November, even before Mitaka b1,
which gave enough time to understand that Reno isn't working the way it
should (ie: it relies on git at "sphinx-build" time, which it shouldn't).

One way I would see to fix the issue, would be having Reno to actually
write the release notes in an RST format, but just *not* when invoking
sphinx-build. Then such a generated file could be stored in the Git
repository of each individual projects, plus a gate job for checking
it's up-to-date could be written. That's of course just an idea, and as
I maintain all of OpenStack packages in Debian (350 source packages and
counting...), I unfortunately can't volunteer to implement it. :/

>
http://lists.openstack.org/pipermail/openstack-dev/2016-February/thread.html#86917

Yeah, that's the thread I am referring to above. Thanks Steve, for
pointing it out so I don't have to do the search myself! :)

It is still my view that projects should revert using Reno asap until
the issue is fixed in Reno. Sure, I could potentially open a bug for
each and every package which has the issue, but IMO that's not the way
to go.

By the way, Reno itself is doing so many gpg keys that the system
building it can't have enough entropy, and then the unit tests are
timing-out. Is there a way to fix this?

Cheers,

Thomas Goirand (zigo)