Hi Doug, Thanks for your reply, it's much appreciated!
On 02/28/2016 11:40 PM, Doug Hellmann wrote: > Excerpts from Thomas Goirand's message of 2016-02-28 22:56:51 +0800: >>> 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 > > Please try to remember that your use case is not the only use case we > have. I get that. Though such a tool should be designed so that it meets the requirements of everyone. That's not the case yet for downstream distributions at least. > Reno was designed to meet a very specific set of criteria and > requirements to solve a problem the release team identified. Building > release notes documents without git history has been on the list of > requirements for quite some time, we just haven't gotten to it yet. The point which I was trying to do, is that until this is fixed, Reno shouldn't be used yet. > I've outlined the approach we have planned in my other email so > I won't repeat it here. Oh, it looks like I missed it. What was the subject? >> 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. > > Projects should not use reno in their developer documentation. The thing is, they do, and I don't see it changed just by writing "please don't do this" in a thread like this one. I wish to be proven wrong though. On 02/28/2016 11:48 PM, Doug Hellmann wrote: > This may not have been widely implemented, so where you're > encountering issues please file bugs. It's relatively simple to fix > the projects for this cycle, in case we don't get the git-free > scanner for reno implemented this cycle. I'll make sure to file bugs as I see it happening, yes. Though it will probably be too late to avoid what I'm expecting (ie: the time of downstream distro package maintainers will be already wasted, and b3 will already be released). >> 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? > > Give this a try and see if it works any better: > https://review.openstack.org/285812 Oh, thanks so much! I'll try and give feedback on review.d.o. Is the issue around the (missed) use of --debug-quick-random? Why do we need Reno unit tests to generate so many GPG keys btw, why not just one or 2? 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