<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2014年10月14日 12:52, Christopher Yeoh
wrote:<br>
</div>
<blockquote cite="mid:20141014152210.3e6858b4@pingu" type="cite">
<pre wrap="">On Mon, 13 Oct 2014 22:20:32 -0400
Jay Pipes <a class="moz-txt-link-rfc2396E" href="mailto:jaypipes@gmail.com"><jaypipes@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 10/13/2014 07:11 PM, Christopher Yeoh wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Mon, 13 Oct 2014 10:52:26 -0400
Jay Pipes <a class="moz-txt-link-rfc2396E" href="mailto:jaypipes@gmail.com"><jaypipes@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 10/10/2014 02:05 AM, Christopher Yeoh wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I agree with what you've written on the wiki page. I think our
priority needs to be to flesh out
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines">https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines</a>
so we have something to reference when reviewing specs. At the
moment I see that document as something anyone should be able to
document a project's API convention even if they conflict with
another project for the moment. Once we've got a fair amount of
content we can start as a group resolving
any conflicts.
</pre>
</blockquote>
<pre wrap="">
Agreed that we should be fleshing out the above wiki page. How
would you like us to do that? Should we have an etherpad to discuss
individual topics? Having multiple people editing the wiki page
offering commentary seems a bit chaotic, and I think we would do
well to have the Gerrit review process in place to handle proposed
guidelines and rules for APIs. See below for specifics on this...
</pre>
</blockquote>
<pre wrap="">
Honestly I don't think we have enough content yet to have much of a
discussion. I started the wiki page
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines">https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines</a>
in the hope that people from other projects would start adding
conventions that they use in their projects. I think its fine for
the moment if its contradictory, we just need to gather what
projects currently do (or want to do) in one place so we can start
discussing any contradictions.
</pre>
</blockquote>
<pre wrap="">
Actually, I don't care all that much about what projects *currently*
do. I want this API working group to come up with concrete guidelines
and rules/examples of what APIs *should* look like.
</pre>
</blockquote>
<pre wrap="">
What projects currently do gives us a baseline to work from. It also
should expose where we have currently have inconsistencies between
projects.
And whilst I don't have a problem with having some guidelines which
suggest a future standard for APIs, I don't think we should be
requiring any type of feature which has not yet been implemented in
at least one, preferably two openstack projects and released and tested
for a cycle. Eg standards should be lagging rather than leading.</pre>
</blockquote>
<br>
There is one reason to think about what projects *currently* do.
When we choice which
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
convention we want.<br>
For example, the CamelCase and snake_case, if the most project use
snake_case, then choice snake_case style<br>
will be the right.<br>
<br>
<blockquote cite="mid:20141014152210.3e6858b4@pingu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">So I'd again encourage anyone interested in APIs from the various
projects to just start dumping their project viewpoint in there.
</pre>
</blockquote>
<pre wrap="">
I went ahead and just created a repository that contained all the
stuff that should be pretty much agreed-to, and a bunch of stub topic
documents that can be used to propose specific ideas (and get
feedback on) here:
<a class="moz-txt-link-freetext" href="http://github.com/jaypipes/openstack-api">http://github.com/jaypipes/openstack-api</a>
Hopefully, you can give it a look and get a feel for why I think the
code review process will be better than the wiki for controlling the
deliverables produced by this team...
</pre>
</blockquote>
<pre wrap="">
I think it will be better in git (but we also need it in gerrit) when
it comes to resolving conflicts and after we've established a decent
document (eg when we have more content). I'm just looking to make it
as easy as possible for anyone to add any guidelines now. Once we've
actually got something to discuss then we use git/gerrit with patches
proposed to resolve conflicts within the document.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I like the idea of a repo and using Gerrit for discussions to
resolve issues. I don't think it works so well when people are
wanting to dump lots of information in initially. Unless we agree
to just merge anything vaguely reasonable and then resolve the
conflicts later when we have a reasonable amount of content.
Otherwise stuff will get lost in gerrit history comments and
people's updates to the document will overwrite each other.
I guess we could also start fleshing out in the repo how we'll work
in practice too (eg once the document is stable what process do we
have for making changes - two +2's is probably not adequate for
something like this).
</pre>
</blockquote>
<pre wrap="">
We can make it work exactly like the openstack/governance repo, where
ttx has the only ability to +2/+W approve a patch for merging, and he
tallies a majority vote from the TC members, who vote -1 or +1 on a
proposed patch.
Instead of ttx, though, we can have an API working group lead
selected from the set of folks currently listed as committed to the
effort?
</pre>
</blockquote>
<pre wrap="">
Yep, that sounds fine, though I don't think a simple majority is
sufficient for something like api standards. We either get consensus
or we don't include it in the final document.
Chris
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>