on would be based on objective 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 - S
operations, 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
N
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
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
How can I 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
I believe my comment may have been [slightly] misinterpreted. I was simply
saying that we shouldn't assume that contributors are allowed to alter their
global configuration. When deciding on a policy for ignoring files, we should
be careful to choose a policy that does not prevent those users fr
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 with
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 pro
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:
xtension with a new name. This allows the alterations
to the core functionality to be linearly versioned independently from the core
function
ality itself.
Thank you,
Sam Harwell
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Tuesday, August 06, 2013 8:46 AM
To: o
10 matches
Mail list logo
