-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update runtime-spec package #140
Conversation
Signed-off-by: Haiyan Meng <hmeng@redhat.com>
On Thu, Jul 21, 2016 at 01:57:50PM -0700, hmeng-19 wrote:
I'd rather only do this on runtime-spec releases; see #108. |
@wking We can start tagging releases to runc releases but I don't see why we can't pull in intermediate code to make progress here. |
On Thu, Jul 21, 2016 at 03:53:05PM -0700, Mrunal Patel wrote:
There are two axes for progress: a. Keeping up with runtime-spec as it evolves, and Historically, ocitools has focused on (a) and neglected (b). As a #108 asks for some kind of plan to move in both directions, and floats |
@wking I think 1.0 is good point for improving b. Till then there is going to be some churn in the spec and we'll have to pick up updates to make progress here. |
On Thu, Jul 21, 2016 at 04:20:44PM -0700, Mrunal Patel wrote:
That means you'll hit 1.0 without (ever?) having validated a runtime's |
We could tag 1.0.0.rc1 and then allow intermediate commits. |
On Thu, Jul 21, 2016 at 04:54:14PM -0700, Mrunal Patel wrote:
The current ocitools validation does not cover runtime-spec 1.0.0-rc1 |
@wking There is always going to be some lag to support all features in the spec. Question is whether it is worth branching off for 1.0.0.rc1? |
On Fri, Jul 22, 2016 at 09:53:01AM -0700, Mrunal Patel wrote:
I think it's worth having an ocitools branch/tag that is as complete |
Yes, we can address #112. I think master should keep tracking the master of the runtime-spec so we don't have to wait for a release. I don't mind us creating a branch/tag for 1.0.0.rc1 if that means that we can keep progressing on master. |
On Fri, Jul 22, 2016 at 10:08:58AM -0700, Mrunal Patel wrote:
I'd recommend a branch, because I don't think the current ocitools So the 1.0.0-rc1 branch would (as long as it existed) always have the |
I have pushed a branch v1.0.0.rc1. |
On Fri, Jul 22, 2016 at 11:08:25AM -0700, Mrunal Patel wrote:
What to do about open PRs targetting master which don't need |
I don't think we need to push all the open PRs to v1.0.0.rc1. They could go into master. Can you identify any PRs that are needed in that branch? If really needed they could be ported to that branch as cherry picks. |
On Fri, Jul 22, 2016 at 11:38:43AM -0700, Mrunal Patel wrote:
I'd like the v1.0.0-rc1 branch to validate cgroups (#93) and mount
If you'd rather push the big green button to land them in master, we o---o----a---o master With (a) being the initial PR and (b) being the v1.0.0-rc1 follow-up And to give my preferred merge-to-v1.0.0-rc1-first approach a graph,
o---o---a---c master where feature-1 is post-v.1.0.0-rc1-specific and lands in master in |
On Mon, Jul 25, 2016 at 01:35:08PM -0700, hmeng-19 wrote:
There's a v1.0.0-rc1 branch now 1, and regardless of what we do with |
LGTM |
In case it helps, I've setup an alternate history where
So just this PR at the moment.
Comparing with our actual
If you use
but the current For folks who want a full graph of both
And the graph of all the commits since this PR's base in both
|
The PR vendors the latest version of the runtime-spec package, and updates generate.go.