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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev