On Mon, Oct 19, 2009 at 7:22 PM, Andre Merzky <andre@merzky.net> wrote:
Quoting [Alexis Richardson] (Oct 19 2009):
I see your point. In other groups, however, the above model worked fine, and having an editor which signes patches to documents would rather be a roadblock than anything else. I mean, the revision control systems all allow branches and tags etc - so it is not like any changes there are hewn in stone. Good processes are in place for software, and the same are applicable for documents in my experiences.
Like: Sam could create a branch OCCI-SAM for editing, which get (partially) merged into OCCI-DRAFT after discussion. Restricting write access to SVN will slow down editing for sure, IMHO.
Personally, I don't mind people creating and editing a branch, so long as the merge algorithm involves acute, chair-mediated, community consensus at specific points in time. alexis
Anyway, this is just my opinion - don't want to impose anything, as I don't edit the doc myself, really...
Best, Andre.
alexis
- before publication or presentation, require a one-week final call on mailing list. Only allow presentation as OCCI draft if group agrees. Otherwise, require label 'my suggestion for OCCI draft' or similar.
Note that OGF requires a final call on the list before submitting to the OGF editor anyway. Submitted documents MUST represent group consensus, i.e. must represent the group majority.
BTW: Voting on issues is explicitely encouraged: IMHO, you disuss issues to death otherwise ("running code and rough consensus"). So:
- discuss issue - consider all alternatives / implementations - if discussion stalls: vote on the issue - *stick* *to* *the* *decision* ;-) - only re-open the discussion IFF - a new alternative emerges - external or internal dependencies of the issue change - implementation is impossible
While I am on it, one more suggestion on procedures in OCCI: Other OGF groups have made tremendous progress in face-to-face meetings, such as during the OGF events, but also outside. The OCCI group members don't seem to massively attend OGF events, really - probably because the group is much more diverse than other OGF groups (which is a good thing!). Anyway, I think you guys should consider a meeting in person: lock a couple of key players in a room for a couple of days, and *decide* on things.
I'd be happy to help to organize a F2F. In fact, I checked with Thilo from the Vrije Universiteit in Amsterdam (VU), and he'd be willing to host, anytime (*).
So, please think about that, and let me know if that would help to settle the open technical issues in OCCI in the near future.
Cheers, Andre.
(*) It is not that VU is contributing to OCCI, but Amsterdam is very convenient to reach for most people, and cheap for Europeans, as EasyJet goes there from many locations. Also, the VU is located about 15 minutes from the Airport (one train stop + 5 min walk). Also, VU is able to cover the cost for the venue. Accomodation is affordable and nearby. I'll rather be silent about Dutch food though... ;-)
alexis
On Mon, Oct 19, 2009 at 5:10 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
Alexis,
I do not believe we can set aside the OGF27 unapproved unilateral change to the document. It is a fundamental problem in operation.
These are my suggestions:
1) Place the document in a format where each interface can have its own life cycle. 2) Create a template for adjunct documents 3) Limit check-in to the repository to two people and one backup. 4) Recruit an editor and a backup editor. This spec isn't that big. 5) Provide an incubator for emerging technologies and proposals for inclusion in the specification. 6) Form a public mailing list purposed for emerging technologies, proposal discussions and voting 7) Provide a proposal document number for each submitted document 8) Before the document can be considered for review, it must be in the adjunct documents template
-gary
Alexis Richardson wrote:
Leaving aside the when and how in relation to OGF 27 specifically, we cannot claim that unilateral changes are supported by the group if they are not supported by the group. I am very concerned about this. We of course don't want to ignore innovative proposals, but we need to build consensus around them before inclusion in the spec.
Suggestions for a good way forward are solicited..
alexis
On Mon, Oct 19, 2009 at 4:19 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
> > That is a good point, a better question would be how did it get into the > spec presented like it was the preferred method. Probably because there > is > no single editor and anyone can change the documents anyway they feel > fit. > > I don't think what Sam is working on is out of scope for OCCI, it was > unintended to support multiple interfaces. Sam seems to be running with > this > one, driving OCCI to the lowest level of the HTTP protocols, essentially > creating a new technology, untried on multiple levels in the internet > infrastructure. > > My issue with it is it was placed in the spec at the last second before > OGF > 27, other implementations were remove in lieu of this one, it was placed > in > the spec irrespective of a group consensus and SNIA, a strategic partner, > publicly announcing they would NOT support this interface. However, this > does not preclude the rest of this group to continue with the original > concept of OCCI information in HTTP entities (content body). > For maintainability, this does force the document to take on a new format > of > separating the implementations from reference model (we need one > first). > Interface implementations should fall into adjunct documents. This > specification model has been successfully executed by numerous standards > bodies. > > cheers, > > Gary > > > Alexis Richardson wrote: > >> >> Sam & group, >> >> I just saw this tweet: http://twitter.com/samj/statuses/4991958514 >> >> You say that "HTTP has an out-of-band metadata channel in the form of >> headers. #occi's using Link: as a flexible, lightweight RDF >> alternative". >> >> I'm a bit confused here.... I thought this was still under discussion. >> What am I missing? >> >> alexis >> _______________________________________________ >> occi-wg mailing list >> occi-wg@ogf.org >> http://www.ogf.org/mailman/listinfo/occi-wg >> >> >> > >
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Nothing is ever easy.
-- Nothing is ever easy.