Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

2015-09-09 Thread Alan Pevec
> I'd like to add in a lower-constraints.txt set of pins and actually
> start reporting on whether our lower bounds *work*.

Do you have a spec in progress for lower-constraints.txt?
It should help catch issues like https://review.openstack.org/221267
There are also lots of entries in global-requirements without minimum
version set while they should:
http://git.openstack.org/cgit/openstack/requirements/tree/README.rst#n226

Cheers,
Alan

__
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


Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

2015-09-09 Thread Robert Collins
On 9 September 2015 at 22:22, Alan Pevec  wrote:
>> I'd like to add in a lower-constraints.txt set of pins and actually
>> start reporting on whether our lower bounds *work*.
>
> Do you have a spec in progress for lower-constraints.txt?
> It should help catch issues like https://review.openstack.org/221267
> There are also lots of entries in global-requirements without minimum
> version set while they should:
> http://git.openstack.org/cgit/openstack/requirements/tree/README.rst#n226

Not yet. Got some other fish to fry first :) - but I'd certainly be
happy to review a spec if someone else wants to work on
lower-constraints testing.

So the bare library thing - I think that advice is overly
prescriptive. Certainly with something like testtools, a bare version
is bad - its a mature library and older versions certainly aren't
relevant today. OTOH with something like os-brick, brand new, all
versions may well be ok.

Cheers,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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


Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

2015-07-09 Thread Doug Hellmann
Excerpts from Robert Collins's message of 2015-07-09 11:07:44 +1200:
 On 9 July 2015 at 09:08, Sean Dague s...@dague.net wrote:
 
  So I think the issue is that we used to have a manual process (reviewing
  g-r adds), and some automated stuff that happens after that.
 
  Now we seem to have a manual process, that triggers some automatic
  stuff, and requires another manual piece before it all works, then
  automatic bits happen.
 
  That seems to just add a lot more error proneness to this. Instead can
  we make this pip resolve process part of the automated testing so that
  it just fails if upper-constraints is incorrect on the g-r proposal?
 
 It already is to a reasonable approximation.
 
 Specifically:
  - we make sure the new g-r can be compiled successfully (see
 tools/integration.sh).
  - we make sure the new upper-constraints.txt and g-r are mutually
 compatible (see openstack_requirements/tests/test_integration.py)

Which job fails if those don't work? Is it a new job, or is it part of
one of the existing jobs?

Doug

 
  I guess I'm missing the part where that has to be done as a second job
  submission instead of at the same time as the g-r proposal.
 
 I think people *should* generate it locally and include it.
 
 We can't fix-it-for them (because we can't change the commit in CI, it
 has to come in well formed).
 We can't require that CI finds the *same result* because noone would
 ever be able to land anything - the landscape moves too fast for our
 review latency.
 
 -Rob
 

__
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