Skip to content

Conversation

@wking
Copy link
Contributor

@wking wking commented Jul 28, 2016

Same as #160, but targeting v1.0.0.rc1.

@Mashimiao
Copy link

The fix seems good. But why just fix v1.0.0.rc1 not master?

@wking
Copy link
Contributor Author

wking commented Jul 28, 2016

On Wed, Jul 27, 2016 at 10:46:20PM -0700, Ma Shimiao wrote:

The fix seems good. But why just fix v1.0.0.rc1 not master?

So we can just merge v1.0.0.rc1 into master periodically to pull
v1.0.0-rc1-compatible changes forward instead of having to file all
these backport PRs 1.

@Mashimiao
Copy link

Got it. I just think it's a little wired. In my opinion, master should be the newest branch.

@wking
Copy link
Contributor Author

wking commented Jul 28, 2016

On Wed, Jul 27, 2016 at 11:07:42PM -0700, Ma Shimiao wrote:

Got it. I just think it's a little wired. In my opinion, master
should be the newest branch.

Master is the newest branch. I just think new commits should target
the oldest compatible branch first, and then we merge the old
branches forward into the newer branches (like Git does 1).

@mrunalp
Copy link
Contributor

mrunalp commented Jul 28, 2016

@wking While that approach sounds good for kernel development, I think that the github model that most developers are used to is submitting PRs to master and backporting to other stable branches.

@wking
Copy link
Contributor Author

wking commented Jul 28, 2016

On Thu, Jul 28, 2016 at 04:05:58PM -0700, Mrunal Patel wrote:

@wking While that approach sounds good for kernel development, I
think that the github model that most developers are used to is
submitting PRs to master and backporting to other stable branches.

It depends on who submits/reviews the v1.0.0.rc1 PRs. I think there
will be less work total if folks PR v1.0.0.rc1 for
1.0.0-rc1-compatible changes, but there will be less work for initial
contributors if they PR master and leave it to someone else to
backport, PR, review, and merge the v1.0.0.rc1 version of their work.
And whether that backport work will get done depends on how seriously
maintainers take the v1.0.0.rc1 branch and minimizing the difference
between it and master (because a smaller difference means easier
sharing between the branches).

@mrunalp
Copy link
Contributor

mrunalp commented Aug 3, 2016

LGTM. But we'll need to get this into master later.

@mrunalp mrunalp merged commit f72c7f5 into opencontainers:v1.0.0.rc1 Aug 3, 2016
@wking wking deleted the superfluous-err-check branch August 3, 2016 05:15
@wking
Copy link
Contributor Author

wking commented Aug 3, 2016

On Tue, Aug 02, 2016 at 05:06:13PM -0700, Mrunal Patel wrote:

LGTM. But we'll need to get this into master later.

I'm setting up a merge from v1.0.0.rc1, but we'll need to catch
v1.0.0.rc1 up with master by backporting recent master work first.
#162 is part of that, and I've just filed #177, #178, and #179. Once
we merge those into v1.0.0.rc1, we should be able to merge v1.0.0.rc1
without unnecessary conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants