Open Stack

Excerpts from Thomas Goirand's message of 2016-02-29 15:15:10 +0800:
> 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.

Yes, I acknowledge that. No software springs into being wholly formed.
We're working on it.

> 
> > 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.

There is one very narrow situation in which you even notice reno exists.
We should avoid that situation, for now. But this particular toothpaste
is already out of the tube.

> 
> > 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 was another reply in this same thread.

> 
> >> 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.

I agree, complaining on email isn't going to do it. File a bug with
a title like "package X cannot be packaged properly" and give
details.  We don't expect everyone in the community to understand
how downstream packaging works, but we do expect them to care when there
are simple actions they can take to help. But you have to use the right
communication mechanism.

> 
> 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?

As you've noticed, reno scans the history of a git repository to find
release notes. It doesn't actually read any of the files from the work
tree. So for tests, we need to create a little git repo and then tag
commits to look like releases. We do that for a bunch of scenarios, and
each test case generates a GPG key to use for signing the tags.

Doug

> 
> Cheers,
> 
> Thomas Goirand (zigo)
>