at you'll save that 100ms over and
>> over, adding up to a huge win.
>>
>
>
> Another data point on how slow our libraries/CLIs can be:
>
> $ time openstack -h
>
> real0m2.491s
> user0m2.378s
> sys 0m0.111s
pbr should be snappy - taking 100ms
On 28 March 2015 at 00:21, Sean Dague wrote:
> On 03/26/2015 06:46 PM, Robert Collins wrote:
...
>> Once everything is covered, and we're dealing with commits that change
>> things async (via the job above), then we can talk about how to help
>> developers submit code u
ilarly.
Looking in your results, I observe significant load in the
steady-state mode for most of the DB's. Thats a little worrying, if as
I assume steady-state means 'no new API calls being made'.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
e can talk about how to help
developers submit code using it in the first place.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage que
the
>> version numbers align wrongly. (All due to accidentially rewinding
>> versions in the presence of pre-release versions). Pbr has generate
>> versions forever. It just generates completely broken ones in t
On 19 March 2015 at 09:21, Jeremy Stanley wrote:
> On 2015-03-19 09:15:36 +1300 (+1300), Robert Collins wrote:
> [...]
>> A second but also mandatory change is to synchronise on the final
>> pre-release tag definitions in PEP-440, IIRC that was just 'rc' ->
>>
a bit further,
so I'd like to suggest we don't do anything right now.
Lets fix up trunk to be releasable and then discuss the next pbr
evolution after that. Juliens work should be incorporatable trivially,
but shims for requirements etc - lets defer for a week or two.
-Rob
--
Robert Coll
I don't expect any OpenStack
> project to directly use a pbr command for creating a tag. Maybe we
> missed the window of opportunity there? How much of that work is done?
> Should we drop any remaining plans?
I think we can defer this part of the conversation.
> Did I miss anythin
ss on transient changes because our
automation hasn't been updated.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: o
On 17 March 2015 at 23:48, Sean Dague wrote:
> On 03/16/2015 10:56 PM, Robert Collins wrote:
...
>> Better at the cost of forcing all existing users to upgrade just to
>> keep using code of their own that already worked.
>>
>> Not really 'better' IMO. Differen
their own that already worked.
Not really 'better' IMO. Different surely.
We could (should) add Warning: headers to inform about this, but
breaking isn't healthy IMO.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
ip/setuptools/whatever now?
Donald says yes, at least for pip (which is all we need, since we
advise folk to use pip install -e . locally).
> If so, an option would be to have pbr recognize the version-specific
> input files as implying a particular rule, and adding that environment
> mar
tested yet (and someone should) that it does all JUST WORK,
but thats easy: put an environment marker in a requirements.txt file
like so:
argparse; python_version < '3'
Build a wheel, unpack it(unzip foo.whl) and cat
foo/*,dist-info/METADATA to check that the marker carried throug
decent approximation. Right now I see 0:00:00.506059 -
or 500ms. On an SSD. Try it on spinning rust and I think you'll cry.
- as a corollary, __init__ should not import things unless *every use
of the library ever* will n
On 17 March 2015 at 09:30, Ben Nemec wrote:
> So I've successfully done a deployment to a QuintupleO environment. \o/
\o/
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development
see them.
>
> Could we maybe have a [release] tag mandated for these?
Rather than adding process, how about we setup automation in zuul for
this. Then email tags etc don't require human thought, training etc.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
On 13 March 2015 at 09:43, Ihar Hrachyshka wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/12/2015 09:35 PM, Robert Collins wrote:
>> On 13 March 2015 at 08:09, Ihar Hrachyshka
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>
ly, all components except
>> oslo have already moved to the new naming scheme.
>
> It's actually wrong. For example, Trove decided to stay on using the
> old namespace for Kilo.
Why?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
s need an optional deps policy (which is
> sounding like the case).
Nit picking just a little, I think this is by definition
cross-project: pbr affects every project, and all the proposals around
this casually propose modifying pbr :). That said I've commented on
both re
is fragile though, so its likely not to
work in many places - wheels will always be a better path forward for
installing it until I get around to some proper magic to fix the
version lookup stuff.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
_
Oh, sure - switching to the spec is fine, I didn't realise there was
one, given the list thread had gone quiet :)
-Rob
On 12 March 2015 at 12:24, Ruby Loo wrote:
> On 11 March 2015 at 18:21, Robert Collins wrote:
> ...
>>
>> Since there was no debate on the compat t
On 12 March 2015 at 13:05, Salvatore Orlando wrote:
> It sounds like we're diverging a bit from the original topic, but...
> whatever.
> Yeah! We should totally work towards a quota service - that's what we said
> back in 2011
:).
> This is a topic that comes back regularly like the Halley's com
On 12 March 2015 at 12:37, Ian Wienand wrote:
> On 03/11/2015 08:10 AM, Robert Collins wrote:
>> The wheel has been removed from PyPI and anyone installing testtools
>> 1.7.0 now will install from source which works fine.
>
> I noticed the centos7 job failed with the so
out what is safe or sane to deploy
: I think that is a risk, but not a big one, because what was safe or
sane to deploy before was already quite fuzzy. See e.g. Neutron only a
couple of releases back :).
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
ood way to abstract that out
- then in consuming code you can reserve, consume and free
appropriately, and the service can take care of being super diligent
about races, correctness, and we'd have one place both in code and
deployments to tune for speed.
-Rob
--
Robert Collins
Distinguished
o expect it will be a
> topic at the Vancouver summit.
Since there was no debate on the compat thing, I've thrown up an
etherpad to start the discussion.
https://etherpad.openstack.org/p/ironic-client-ux
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
too.
>
> Can we sanely run a 2 node galera in a single node devstack? It might
> make for a more interesting default there given that time and again this
> seems to be the deployment strategy for nearly everyone, and there are
> some edge case differences that Jay Pipes has h
On 11 March 2015 at 13:59, Robert Collins wrote:
> On 11 March 2015 at 10:27, Dolph Mathews wrote:
>> Great to hear that this has been addressed, as this impacted a few tests in
>> keystone.
>>
>> (but why was the fix not released as 1.7.1?)
>
> There will be a
testtools CI, but the actual bug affecting
1.7.0 on Python2 was entirely in the build process, not in the release
itself.
The built wheel was corrupt (missing files), as opposed to there being
a bug in the code itself.
-Rob
--
Robert Collins
Distinguished Technologist
HP Con
installing testtools
1.7.0 now will install from source which works fine.
Cheers,
Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
And I forgot my references. Doh.
On 10 March 2015 at 12:57, Robert Collins wrote:
> I've just finished[1] an arc of development adding showing frame local
> variables in tracebacks to our testing stack[2]. Its off by default
> since its new and doesn't have the depth of p
licit
cons: turning off will require a change to each project as it won't
be centrally set
Assuming the variable option makes the most sense (I think it does), I
propose to call the variable OS_CI_LOCALS.
Bikeshed time^W^Wcomment thoughtfully :)
-Rob
--
Robert Collins
Distinguished T
ld have caps and not pins.
>> > > > >
>> > > > > /Ihar
>> > > > > -BEGIN PGP SIGNATURE-
>> > > > > Version: GnuPG v1
>> > > > >
>> > > &g
Some
> rule-of-thumb would be helpful to me.
>
> Thoughts?
I think improvements are improvements and we should welcome them - and
allow single +2/+A so long as they are not touching code.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
ng at the code you can
tell where a name came from. If the code is using libraries that one
is not familiar with, this makes finding the implementation a lot
easier (than e.g. googling it and hoping its unique and not generic
like 'create&
og with enough detail that we can report on the actual concurrency
achieved. E.g. log the time in us when each transaction starts and
finishes, then we can assess how many concurrent requests were
actually running.
If the results are still the same - great, full steam ahead. If
we're back to
> the current model again.
I don't think thats true actually. We'd still have a major smoothing
effect on work, which means less high peaks at release time and less
troughs at 'review direction' time and so on.
-Rob
--
Robert Collins
Distinguished Te
Like with TripleO, I've not been pulling my weight as a core reviewer
for a bit; I'd be very hesitant to +A in the project as a result.
I'm still very interested in Ironic, but its not where my immediate focus is.
Cheers,
Rob
--
Robert Collins
Distinguished Technologist
HP
ve to
backup the change with the appropriate engineering (such as reducing
our frictions that cause teams practicing CD to be weeks behind tip)
to make it feasible. My greatest concern about the proposals happening
now is that we may bite off more than we can chew. OTGH the reality is
that all the neg
ions leading to the branch a
patch is for, so changes to Aug would need c, e and f all tested.
Thats 3 times the overhead of supporting:
Feb->Apr and then
Apr->Jun and then
Jun->Aug
serially where we'd only be testing one combination at a time.
-Rob
--
Robert Collins
Di
nts.txt constraints...)
> Regarding public API and 1.x.y, I don't think there is really anything
> holding sqlalchemy-migrate back from that, it's hella old so we should
> probably be 1.0.0 by now.
+1.
-Rob
rare that I think we can defer adding apis to support
them (e.g. a way to say 'ok, refresh your cache of the pid now') until
someone actually wants that.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
_
expect to do .y increases - is
probably good enough for a while yet.
-Rob
[1]: The special case is for projects that have not yet committed to a
public API - 0.x.y versions. Don't do that. Commit to a public API :)
--
Robert Collins
Distinguished T
On 20 February 2015 at 08:32, Morgan Fainberg wrote:
> The Keystone development team is planning to deprecate deployment of
> Keystone under Eventlet during the Kilo cycle. Support for deploying under
> eventlet will be dropped as of the “M”-release of OpenStack.
\o/
-Rob
--
Rober
On 16 Feb 2015 03:56, "Sean Dague" wrote:
Fixtures seems to be doing the
> right thing with it's copy.
I'm glad you sorted the issue out. If it had been a fixtures issue I would
have considered it a critical bug and dived on it... The testing cabal set
of libraries are many to be bulletproof
tly support
multiple plugins. I hope you don't mean you're doing the same thing :)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage ques
to each machine - if you like.
Or a pool of SNAT addresses ~= to the size of the hypervisor count.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage
't be migrated by it
but instead are known to be networked etc? Or put another way, how can
we have our cake and eat it too. Its not uncommon for a VM to be
cinder booted but have local storage for swap... and AIUI the fix we
put in for this bug stops those VM's being migrated. Do you think
ow. We'll see where we're at in a cycle or two :)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
Argh. Wrong thread. Sorry. I was aiming for one about logging :(
On 14 Feb 2015 01:48, "Jay Pipes" wrote:
> On 02/12/2015 09:59 PM, Robert Collins wrote:
>
>> On 5 February 2015 at 13:20, Rochelle Grober
>> wrote:
>>
>>> Duncan Thomas [mailto:dunc
What's the test path thing for? Testr should be able to filter out unit
tests or vice versa without altering discovery.
On 14 Feb 2015 08:57, "Joe Gordon" wrote:
>
>1.
> A few months back we started the process to remove the tempest CLI
> tests from tempest [0]. Now that we have s
On 13 Feb 2015 17:42, "Angus Lees" wrote:
>
> So inspired by the "Rootwrap on root-intensive nodes" thread, I went and
wrote a proof-of-concept privsep daemon for neutron:
https://review.openstack.org/#/c/155631
> There's nothing neutron-specific in the core mechanism and it could
easily be moved
s of logging, has https://tools.ietf.org/html/rfc5424 been
considered? Combined with https://tools.ietf.org/html/rfc5426 we'd
have a standards based (and thus already supported by logging and
analysis tools) framework. aka, we seem to be on the verge of
inventing a thing thats already been in
too on design and speccing for this. I realise that for
some cases rootwrap was absolutely a performance and stability issue,
but daemon mode should address that - so I think this is a longer term
project, giving us a significant step up in security.
-Rob
--
Robert Collins
Distinguish
well, and it may be that this layer is the wrong layer to apply it at
- thats certainly a possibility.
> Are the people that are using it know/aware that this happens? :-/
I hope so :)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
field was bad.
Structured data (e.g. JSON) is a whole different kettle of fish, as it
could have a freeform field but also a machine understood field (be
that numeric, an enumeration or whatever).
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
n uncommon operation on physical machines is to
replace broken NICs, and forcing a redeploy seemed unreasonable. The
former case doesn't affect running nodes since its only consulted on
reboot. The second case is by definition only possible when the NIC in
question is offline (whether hotplu
gt; Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenS
es the power to manage
things to admins without us having to write a probably-too-simple
config interface.
HTH,
Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for u
backwards compat. This
> probably made some sense at the time of the spec writing since
> alternatives to tripleo-image-elements did not exist, but with the
> tripleo/puppet work we need to revisit this.
>
> Thoughts? Comments?
How will upgrade work? Since we deploy the new s
fic
> solution the right thing to do?
I think your desire and Salvatore's are compatible: an interface that
is excellent for Nova can also be excellent for other users.
Notifications aren't a complete solution to the orphaning issue unless
the notification system is guaranteed non-loss
ne big "openstack"
> venv now.
Yes, but the experience we have about the limitations of per-service
venvs is still relevant, no? Are you really saying 'do per-service
venvs because they work well', or are you agreeing with me that they
don't solve the problems p
e Gordon wrote:
>
>
> On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague wrote:
>>
>> On 01/20/2015 08:15 PM, Robert Collins wrote:
>> > On 21 January 2015 at 10:21, Clark Boylan wrote:
>> > ...
>> >> This ml thread came up in the TC meeting today and I am respo
questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
bout to release won't
break folk as well as knowing that the thing we're about to release
works with the releases of other things that are already out there.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
_
#x27;t about
random packages, it was about other stackforge clients - these are
things in the ecosystem! I'm glad we have technical solutions, but it
just seems odd to me that adding them would ever have been
controversial.
On the pip solver side, joe gordon was working on a thing to install
o 3 per day is to maintain
> familiarity with the code. I think you've been able to remain familiar
> with your traditional rate just fine.
3 was an arbitrary number pulled out of the air. If folk can and do
remain familiar with a lower review rate, thats fine IMO. Nothing
should be cons
+1
On 15 Jan 2015 07:15, "Clint Byrum" wrote:
> Hello! It has been a while since we expanded our review team. The
> numbers aren't easy to read with recent dips caused by the summit and
> holidays. However, I believe James has demonstrated superb review skills
> and a commitment to the project th
st pass them through, and in principle
multiplexing is possible for multiple backends, but thats not
implemented yet.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rs that have entirely different backends for various services
to plug into.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ears ago. :)
Nova managed it in Jan 2011, so 3.5 mumblemumble. Near enough to 'just' :)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
;
- the option that Glyph (and I too) would say to never ever choose.
My concern isn't that asyncio is bad - its not. Its that we spent an
awful lot of time and effort rewriting nova etc to be 'option 4', and
we've no reason to believe that whatever it was that made that no
I'm also concerned that it will surprise
folk - since there doesn't seem to be a cross project blueprint
talking about this fairly fundamental shift in programming model.
-Rob
--
Robert Collins
Distinguished Technologistste
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 23 November 2014 at 11:01, Jeremy Stanley wrote:
> On 2014-11-22 19:45:09 +1300 (+1300), Robert Collins wrote:
>> Given the persistent risks of downgrade attacks, I think this does
>> actually qualify as a security issue: not that its breaking, but
>> that SSLv3 is ad
https://github.com/mpaladin/python-amqpclt/blob/master/amqpclt/kombu.py#L101
is truely egregious!
:)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rg
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
n not running the tests. A
subunit point release will be needed in order to consume that data,
which will probably be 1.0.0.
I'll send a followup when everything is in releases.
Cheers,
-Rob
--
Robert Collins
Distinguished Technologist
HP Conve
consuming resources
> which means that parts of the project that could pass tests, is backed
> up behind 100% guarunteed failing parts. All in all, not a great system.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
e OpenStack
existed :) - testtools has kept 2.6 support because a) its easy and b)
there are still groups (like but not limited to OpenStack) that care
about it.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to kick-off the job again. I would appreciate it
> if you could kick it off again when you get a chance.
>
> Cheers,
> Nikhil
>
> On Sun, Nov 16, 2014 at 6:44 PM, Robert Collins
> wrote:
>>
>> On 17 November 2014 11:29, Alan Pevec wrote:
>> > 2014-11-15
On 17 November 2014 11:29, Alan Pevec wrote:
> 2014-11-15 23:06 GMT+01:00 Robert Collins :
>> We did find a further issue, which was due to the use of setUpClass in
>> tempest (a thing that testtools has never supported per se - its
>> always been a happy accident that it wo
On 17 November 2014 11:29, Alan Pevec wrote:
> 2014-11-15 23:06 GMT+01:00 Robert Collins :
>> We did find a further issue, which was due to the use of setUpClass in
>> tempest (a thing that testtools has never supported per se - its
>> always been a happy accident that it wo
On 16 November 2014 09:06, Robert Collins wrote:
> On 16 November 2014 03:25, Sean Dague wrote:
>> Testtools 1.2.0 release apparently broke subunit.run discover --list
>> which breaks the way that tempest calls the test chain. No tempest runs
>> have passed since it
On 16 November 2014 09:38, Dave Walker wrote:
> On 15 November 2014 20:23, Robert Collins wrote:
>> On 16 November 2014 09:03, Dave Walker wrote:
>>> On 15 November 2014 19:51, Robert Collins wrote:
>>>> It probably needs to be backed out of stable/icehouse.
On 16 November 2014 09:03, Dave Walker wrote:
> On 15 November 2014 19:51, Robert Collins wrote:
>> It probably needs to be backed out of stable/icehouse. The issue is
>> that we were installing unittest2 via distro packages *and* testtools
>> new dependency on unitte
running with stale dependencies isn't
going to be part of the test matrix upstream, since the entire project
goal is to fold all its learning into upstream: as things move
upstream we have to depend on newer releases of those components (via
things like unittest2, importlib2, traceback2 etc etc
727/
>
> This should unblock stable/juno, allowing this to progress.
>
> Please be reviewing :)
>
> --
> Kind Regards,
> Dave Walker
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openst
Thoughts? Suggestions? I feel like this might take some time, but it is
> necessary to consider it now so we can drive any work we need to get it
> done soon.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.opensta
do to get this usable by other
> projects in a timely manner?
+1 on protocol buffers, but perhaps
http://kentonv.github.io/capnproto/ could be considered: its protocol
buffers v2 basically - from one of the originators of protocol
buffers. It has Python support available too, just like protoc
I think the upload command since we favor using twine over direct uploads. I
> can’t promise fast reviews this cycle, since most of the team is going to be
> focused on continuing to graduate code from the incubator, but it sounds
> like most of what you have to propose is not very con
On 7 Nov 2014 16:57, "Ian Wienand" wrote:
>
> On 10/29/2014 12:42 AM, Doug Hellmann wrote:
>>
>> Another way to do this, which has been used in some other projects,
>> is to define one option for a list of “names” of things, and use
>> those names to make groups with each field
>
>
> I've proposed
What changes do you want to see in the ui?
On 7 Nov 2014 17:17, "Chris Dent" wrote:
> On Fri, 7 Nov 2014, Dmitriy Shulyak wrote:
>
> As for testrepository - if you have positive experience using this tool,
>> share them, from my point of view it has very bad UX.
>>
>
> +1, but with the caveat th
ly I think a separate yaml file would be a bit nicer.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
oint release, not at it. If we drop support earlier, we can't
release the support dropping versions until the support period ends,
and that means we'd have an unreleasable trunk, which is bad.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
_
e if there's a significant long-tail of
>> potential voters with very few patches.
>
> Just looking at stackalytices numbers for Juno: Out of 1556 committers,
> 1071 have committed more than one patch and 485 only a single patch.
> That's a third!
>
> Andreas
> --
> Andreas Jaeger aj@{suse.com,opensuse
and simplicity (i.e. As defined by Rich Hickey).
I won't throw anything at you; I might buy you a drink.
For folk that haven't seen it:
http://www.infoq.com/presentations/Simple-Made-Easy //
http://www.reddit.com/r/programming/comments/lirke/simple_made_easy_by_rich_hickey_video/
On 28 October 2014 22:51, Steven Hardy wrote:
> On Tue, Oct 28, 2014 at 03:22:36PM +1300, Robert Collins wrote:
>> So this should work and I think its generally good.
>>
>> But - I'm curious, you only need a single image for devtest to
>> experiment with tuskar -
to 1?)
>
> I'd be interested in peoples thoughts about this general approach - ideally
> I'd like to end up at a point where you could launch an overcloud template
> directly via heat on devstack (with ironic enabled and the appropriate
> controller/compute images in glanc
On 15 October 2014 14:36, Kevin Benton wrote:
> One cannot simply prevent bike-shedding by asking people to do it up front
> on the mailing list.
> You'll have to wait until review time like everyone else. ;-)
http://i.imgur.com/bNIZEKp.jpg
--
Robert Collins
Distinguished T
ed in the Google python styleguide)
> c. NOQA_foo (as suggested in c/117418)
> d. No convention (including not indicating that variables are known-unused)
I would say a) and don't signal function parameter use via the
parameter names: the only reason to have unused p
401 - 500 of 1124 matches
Mail list logo
