results.
Thank you,
Sam Harwell
From: Amit Gandhi [mailto:amit.gan...@rackspace.com]
Sent: Friday, October 17, 2014 12:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: r...@ryanpetrello.com
Subject: [openstack-dev] [api] Request Validation - Stoplight
Hi API Working Group
, separately
from the fundamental status reporting behavior.
Thank you,
Sam Harwell
-Original Message-
From: Kevin L. Mitchell [mailto:kevin.mitch...@rackspace.com]
Sent: Wednesday, October 15, 2014 10:49 AM
To: openstack-dev
Subject: [openstack-dev] [api] API recommendation
Now that we
for when a
service includes optional functionality is listed under the heading “Conceptual
Grouping” in the following document:
https://github.com/sharwell/openstack.net/wiki/The-JSON-Checklist
Thank you,
Sam Harwell
From: Kurt Griffiths [mailto:kurt.griffi...@rackspace.com]
Sent: Monday, June 09
determine this information according to the documentation?
Thank you,
Sam Harwell
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
information is available through
the API their applications are using. This is (or should be) the primary driver
for design decisions made during the creation of each API.
Thank you,
Sam Harwell
-Original Message-
From: Robert Collins [mailto:robe...@robertcollins.net]
Sent: Tuesday, June 03
OpenStack does not have operational or administrative ownership over the
computers used by contributors. As such, the community should not accept or
promote any policy which suggests a configuration that alters the behavior of
systems beyond the scope of a local workspace used while working
Nottingham's RFC is exceptionally well documented. I would be strongly against
Marconi moving from that RFC to any other format unless the alternative was
equally well documented. If they were equally well documented, then I would be
neutral on changing it.
More importantly, if a project is
I like to take a different approach. If my commit message is going to take more
than a couple lines for people to understand the decisions I made, I go and
make an issue in the issue tracker before committing locally and then reference
that issue in the commit message. This helps in a few ways:
