Open Stack

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)