4.5 should be merged. no individual commits.
Op vr 22 mei 2015 om 06:22 schreef Rajani Karuturi raj...@apache.org:
Are we merging from 4.5 to master or doing individual commits?
I see that both are being followed. It makes merging very easy if everybody
follows it.
~Rajani
that must have been a while ago, was it? after 4.5 I did a merge with only
minor problems.
Op vr 22 mei 2015 om 12:33 schreef Rajani Karuturi raj...@apache.org:
When I tried to do it, I saw lot of conflicts especially in dbupgrade file.
On Fri, May 22, 2015 at 13:05 PM, Daan Hoogland
When I tried to do it, I saw lot of conflicts especially in dbupgrade file.
On Fri, May 22, 2015 at 13:05 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:
4.5 should be merged. no individual commits.
Op vr 22 mei 2015 om 06:22 schreef Rajani Karuturi raj...@apache.org
javascript:;:
Are we
not sure daan.
Check the branch merge-45-to-master[1] for the conflicts
If we agree to only do merge from 4.5, then its worth resolving. Otherwise,
its a waste of time for the one who does the merge, with folks doing high
density individual commits.
[1]
As one of the folks who are doing *that* (and also travelling), I did not know
if there are people merging branches or if there was a planned 4.5 to master
merge.
Some of the things I’m fixing wrt KVM needs to be manually cherry-picked or
fixed due to recent refactoring work, so I may be
Hey Mike,
In git you accomplish these kinds of things with merge strategies. There’s a
lot to choose from. What you’re describing sounds a bit like a variant on the
“theirs” strategy. You can also do a recursive merge with a “theirs” conflict
resolution choice, and there’s many other options.
On Fri, Oct 24, 2014 at 8:36 AM, Leo Simons lsim...@schubergphilis.com wrote:
Hey Mike,
In git you accomplish these kinds of things with merge strategies. There’s a
lot to choose from. What you’re describing sounds a bit like a variant on the
“theirs” strategy.
...
doh, will give it another
Thanks, Leo
Yeah, being able to essentially mark a commit as NOT needing to be merged
(in fact, merging is wrong in this case) to a newer branch is key, I think,
to helping solve our branching issues.
On Fri, Oct 24, 2014 at 12:36 AM, Leo Simons lsim...@schubergphilis.com
wrote:
Hey Mike,
In
great hope you didn't check it into master so wecan see if the merge
strategy works:)
On Wed, Oct 22, 2014 at 11:57 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
Just an FYI that I checked code directly into 4.5 today, but it was only
related to the SolidFire driver (no general-purpose
Actually...this was a 4.5-only change.
On Thursday, October 23, 2014, Daan Hoogland daan.hoogl...@gmail.com
wrote:
great hope you didn't check it into master so wecan see if the merge
strategy works:)
On Wed, Oct 22, 2014 at 11:57 PM, Mike Tutkowski
mike.tutkow...@solidfire.com javascript:;
not nice, so merge back is no longer an option. I think I am almost
ready to admit to that.
On Thu, Oct 23, 2014 at 3:31 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
Actually...this was a 4.5-only change.
On Thursday, October 23, 2014, Daan Hoogland daan.hoogl...@gmail.com
wrote:
Yes, certain things checked into a version like 4.5 need to make sure they
never make it to master.
SVN has a way to mark a commit so it would not be merged to another branch
like master is for us. I don't know if I Git has such a feature.
On Thursday, October 23, 2014, Daan Hoogland
On Thu, Oct 23, 2014 at 10:05 AM, Daan Hoogland daan.hoogl...@gmail.com wrote:
not nice, so merge back is no longer an option. I think I am almost
ready to admit to that.
I came to that conclusion a week or so ago.
If we could keep master as the release branch until we were imminently
If we just did merges (instead of cherry picks) to 4.5, does Git allow us
to ONLY merge that particular (merge) commit from 4.5 to master?
In other words, I'd want to make sure we were only merging from 4.5 to
master what we want to (and, as I mentioned earlier, not bring along
commits to 4.5
Just to be clear (I've now had a couple questions about this)
4.5 branch is still open for bug fixes from folks. It is closed to new
functionality/features, but remains open to bug fixes.
master already has a few new features in it (compared to 4.5)
Code freeze will happen for 4.5, but will be
Maybe we need something like this in Git (maybe it's already there?):
http://stackoverflow.com/questions/18074697/subversion-mark-as-merged-without-changing-anything
The ability to record a commit has having been merged to another branch,
but nothing was really merged.
Then when you checked
If we had something like that, then we could still have the general rule:
Everything put in 4.5 must be merged to master (but the person to merge
would have to decide if they just need to do a --record-only kind of merge).
On Thu, Oct 23, 2014 at 6:29 PM, Mike Tutkowski
That would be way better than cherry picking since we could then trace
related commits across branches easily.
On Thu, Oct 23, 2014 at 6:30 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
If we had something like that, then we could still have the general rule:
Everything put in 4.5
Just an FYI that I checked code directly into 4.5 today, but it was only
related to the SolidFire driver (no general-purpose CloudStack code was
part of the commit).
2d7187e002e6b5b164c226fdde994a3a92cb9dda
On Tue, Oct 21, 2014 at 10:50 AM, David Nalley da...@gnsa.us wrote:
We are well past
Hi Daan,
Do you know if the check-in protocol for 4.5 (or rather for any branched
release) is formally documented on the Wiki somewhere?
If it's not, it's probably harder to enforce it.
Thanks!
Mike
On Tue, Oct 21, 2014 at 1:21 AM, Daan Hoogland daan.hoogl...@gmail.com
wrote:
David,
I keep
We are well past feature freeze - but I haven't started a hard code
freeze; though it is imminent.
--David
On Tue, Oct 21, 2014 at 12:46 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
Hi Daan,
Do you know if the check-in protocol for 4.5 (or rather for any branched
release) is
Sorry, I am not aware of the 4.5 release policy, I'll revert my commits on 4.5.
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: Tuesday, October 21, 2014 12:22 AM
To: dev; David Nalley
Subject: commits on 4.5
David,
I keep seeing commits passing to
So, in the past, feature freeze has been when we branch from master (in
this case, 4.5) and then people check directly into 4.5 until the RM has
called code freeze (at which point, we started using that -forward concept).
Where did we land on that? Once code freeze has passed, do people need to
I would hold off on that, Edison.
We need to make sure the policy is clear (and probably documented) first.
On Tue, Oct 21, 2014 at 10:57 AM, Edison Su edison...@citrix.com wrote:
Sorry, I am not aware of the 4.5 release policy, I'll revert my commits on
4.5.
-Original Message-
I wouldn't do that either Edison, that's up to David. I think the
practice of making hotfix branches is good in any case.
The thing that worries me most is that commits are being entered
seperately on both 45 and master instead of merging back.
On Tue, Oct 21, 2014 at 7:01 PM, Mike Tutkowski
25 matches
Mail list logo
