On Thu, Mar 09, 2017 at 08:37:55AM -0700, Chris Aniszczyk wrote [1]:
> summarizing the discussion, how about we just alternative the time like
> Jonathan discussed?
>
> I believe that's the only fair thing to do and it's reassuring to hear from
> people like Phil who would be able to make the time along with others.
>
> I'm fine with the current time (1000AEST/1500PST/0000CET) and then
> 0400AEST/0900PST/1800CET
The 8am Pacific time ended up working out better than 9am for Jonathan
and Samuel [2,3], so I've used that instead of 9am. The 8am slot was
confirmed as the most popular slot in a Doodle poll [4], with the
following folks approving that slot:
* David Lyle
* George Lestaris
* Jonathan Boulle
* Julz
* Michael Crosby
* Mike Brown
* Mrunal Patel
* Phil Estes
* Rob Dolin
* Samuel Ortiz
* Stephen Day
* Stephen Walli
* Vincent Batts
* W. Trevor King
Removing those folks, the second most popular slot is 5pm Pacific,
with the following folks approving that slot:
* Aleksa Sarai
* Keyang Xie
* Lei Jitang
* Ma Shimiao
* Qiang Huang
Stephen and Mrunal approved both slots, and since they frequently
anchor the runtime and image conversations respectively, there should
be sufficient continuity between the two meetings.
The only person voting in the Doodle poll who didn't approve either
slot is Tianon.
Folks with a POSIX ‘date’ command can find the week number with [5]:
$ date +%V
There may be some doubling up around the end of the year, but we're
usually canceling meetings around then anyway.
The 8am Pacific meeting gets the odd slot because it's Europe-friendly
and lots of folks will be in Europe on 2017-03-29 for KubeCon [6].
I'd be happier with meeting times anchored to UTC to make life easier
for folks outside of the US, but one change at a time ;).
Future bumps to meeting.ics should bump LAST-MODIFIED [7] or DTSTAMP
[8] for any altered components. We can't use DTSTAMP in the VEVENT
because VEVENTs require DTSTAMP [9].
The timezone entry is based on the America/New_York example from [10].
Figuring out a single RRULE to cover both meeting times was beyond my
abilities, and while RFC 2445 allowed multiple RRULEs in a single
VEVENT [11,12], RFC 5545 does not [13]. Something like:
RRULE:FREQ=YEARLY;BYDAY=WE;BYHOUR=8,17;BYSETPOS=1,4,5,8,9,...
should be legal (at least for 2017), but Google Calendar [14] doesn't
seem to respect BYHOUR expansion, and ICAL.js [15] doesn't seem to
respect the BYSETPOS limit, so I gave it up and went with two events.
To stick strictly to the ISO weeks we could use:
RRULE:FREQ=YEARLY;BYDAY=WE;BYWEEKNO=13,15,17,19,21,23,25,27,29,31,33,35,
37,39,41,43,45,47,49,51
and:
RRULE:FREQ=YEARLY;BYDAY=WE;BYWEEKNO=14,16,18,20,22,24,26,28,30,32,34,36,
38,40,42,44,46,48,50,52
but that's tedious to type, and folks probably don't care all that
much about ISO weeks. I've gone with WEEKLY and INTERVAL=2 to give us
something that might survive the end of the year.
The ICS was validated with [16].
The CRLF line endings are intentional [17], and the .gitattributes
entry ensures we keep them. The committed files will still have LF
endings, which can confuse 'git diff ...', but you can use
--ignore-space-at-eol to see what really changed.
[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/p0mTOspVgd0/mh7FYse2BAAJ
Subject: Re: Moving the OCI Call (again)
Date: Thu, 9 Mar 2017 08:37:55 -0700
Message-ID: <CAJg1wMTCGEFRuKoKBEbUPdho82TVH8sPZdGORK_NA2vCNe+w9w@mail.gmail.com>
[2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/p0mTOspVgd0/ULXnARy9BAAJ
Subject: Re: Moving the OCI Call (again)
Date: Thu, 9 Mar 2017 18:33:34 +0100
Message-ID: <CAPWU_0rByhFp=jQQ6cvagHJuYmeTvN7T1zAW+oZR3=F1W8b_rw@mail.gmail.com>
[3]: https://github.com/opencontainers/runtime-spec/pull/719#pullrequestreview-26109314
[4]: http://doodle.com/poll/zu664785gb59pwkg
[5]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html
[6]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-03-22-21.00.log.html
[7]: https://tools.ietf.org/html/rfc5545#section-3.8.7.3
[8]: https://tools.ietf.org/html/rfc5545#section-3.8.7.2
[9]: https://tools.ietf.org/html/rfc5545#section-3.6.1
[10]: https://tools.ietf.org/html/rfc5545#page-69
[11]: https://tools.ietf.org/html/rfc2445#section-4.6.1
[12]: https://tools.ietf.org/html/rfc2445#section-4.8.5.4
[13]: https://tools.ietf.org/html/rfc5545#appendix-A.1
[14]: https://calendar.google.com/
[15]: http://mozilla-comm.github.io/ical.js/
[16]: https://icalendar.org/validator.html
[17]: https://tools.ietf.org/html/rfc5545#section-3.1
Signed-off-by: W. Trevor King <wking@tremily.us>
Match the recommendation in the RFC's abstract [1]. Also bump
"keywords" -> "key words" in the subsequent C99 sentence for
consistency.
[1]: https://tools.ietf.org/html/rfc2119
Signed-off-by: W. Trevor King <wking@tremily.us>
All of these sections are about configuration, and we don't usually
use "{Whatever} configuration" in the headers.
Signed-off-by: W. Trevor King <wking@tremily.us>
On Thu, Jul 14, 2016 at 06:27:50PM -0700, Chris Aniszczyk wrote [1]:
> There was a change in the phone number for the conference line, URL
> is the same.
>
> Join the call: https://www.uberconference.com/opencontainers
> Optional dial in number: 415-968-0849
> No PIN needed
[1]: https://github.com/opencontainers/runtime-spec/issues/514
Reported-by: Chris Aniszczyk <caniszczyk@gmail.com>
Signed-off-by: W. Trevor King <wking@tremily.us>
With:
$ sed -i 's/[[:space:]]*$//' README.md
fixing some trailing whitespace that snuck in with ca0803d1
(Additional language for conformance statement, 2016-04-06, #374).
Future occurrences should be caught by git-validation, which checks
for whitespace issues since [1,2].
[1]: https://github.com/vbatts/git-validation/pull/7
[2]: https://github.com/vbatts/git-validation/pull/9
Signed-off-by: W. Trevor King <wking@tremily.us>
Weekly call is for all OCI projects and per discussion on today's call,
updates to indicate the call is for all OCI projects (rather than having
multiple calls.)
And updates time zone description from PST/PDT to Pacific time
Signed-off-by: Rob Dolin <RobDolin@microsoft.com>
Proposed additional conformance language to support future certification work (cribbed from https://tools.ietf.org/html/rfc2616).
Signed-off-by: Stephen R. Walli <stephen.walli@gmail.com>
This is style information, even though it's about the spec and not
about the behavior covered by the spec. The Go-pointer rule is also
about more peripheral stuff though, and the README has a lot of stuff
in it, so it seems like a better fit after the move.
Signed-off-by: W. Trevor King <wking@tremily.us>
The only reference was removed in 15a43acd (ReadMe: Replace BlueJeans
with UberConference, 2016-02-24, #326).
Signed-off-by: W. Trevor King <wking@tremily.us>
Update the Table of Contents section of the ReadMe.md to match the order
of the merged MarkDown files in the printable HTML and PDF outputs
Signed-off-by: Rob Dolin <RobDolin@microsoft.com>
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
Lets call out some users directly and give them titles. Then define what
they is trying to do.
Signed-off-by: Brandon Philips <brandon.philips@coreos.com>
So we have something to cite to avoid rehashing established decisions.
Provide some motivation and links to the backing discussion so folks
can re-open these if they have new information that wasn't covered in
the original decision.
Like the glossary (18734986, glossary: Provide a quick overview of
important terms, 2015-08-11, #107), I've used subsection titles for
each entry to get link anchors.
Signed-off-by: W. Trevor King <wking@tremily.us>
And link them to the more detailed specification.
Subsection titles for the entries will be obnoxiously spacious, but
the other alternatives seem worse:
a. An HTML definition list (<dl>) would have nice default styling, but
it's annoying to write raw HTML. And we would have needed
something like:
<dt name="bundle">Bundle</dt>
<dd>
A [directory structure](bundle.md) that is...
</dd>
to get Markdown-style links in the defintion itself.
b. A Markdown list (* ...) would have reasonable default styling, but
there's no Markdown syntax for adding anchors to the entries. And
a glossary is much less useful if you can't link to a specific
entry.
Signed-off-by: W. Trevor King <wking@tremily.us>