Discussion attached.
We decided to handle integration between the master and metamodel
branches by doing intermediate merges from master to metamodel and
ultimately rebasing metamodel on top of master for the final integration.
--
st...@hibernate.org
http://hibernate.org
[08:33] <sebersole> i just wanted to discuss (1) blog site and (2)
metamodel/master synching
[08:33] <sebersole> though i guess we can just keep going on (1) on email
[08:34] <sebersole> hardy_: ^^
[08:34] <hardy_> ahh
[08:35] <sebersole> but we really have not had much to discuss the last few
meetings
[08:35] <hardy_> yeah, need to get some stuff
[08:35] <hardy_> right
[08:35] <sebersole> felt like a bit of a soliloquoy ;)
[08:35] <hardy_> gee, does this word exist for real?
[08:36] <sebersole> hehe
[08:36] <sebersole> talking to oneself
[08:36] <hardy_> right
[08:36] <hardy_> monolog is the word I would know
[08:36] <sebersole> ah, thats a bit diff
[08:37] <sebersole> the audience is the diff
[08:37] <sebersole> yourself versus others
[08:37] <hardy_> sure, get it
[08:37] <sebersole> ok
[08:37] <hardy_> jupp
[08:37] <hardy_> cool, just learned a new word
[08:37] <sebersole> you have to remember my degree is in lit :D
[08:37] <hardy_> :-)
[08:38] <-- madhumita has left this server (Ping timeout: 244 seconds).
[08:38] <hardy_> problem is I won't be able to remember it, because I cannot
even imagine how to pronounce it :-)
[08:38] <sebersole> you have time to chat about (2) now?
[08:38] <hardy_> sure
[08:38] <sebersole> i am just trying to understand the implications of the diff
approaxches
[08:38] <hardy_> regarding (1) I think it is best to be continued on the email
thread
[08:39] <sebersole> is merging really what we want?
[08:39] <hardy_> my preference is awestruct on Openshift, but anyways
[08:39] <hardy_> which different approaches?
[08:39] <sebersole> well i see a few approaches
[08:40] <sebersole> 1) merge master -> metamodel; eventually merge metamodel ->
master
[08:40] <sebersole> 1) merge master -> metamodel; eventually rebase master ->
metamodel + merge -> master
[08:40] <sebersole> grr
[08:40] <sebersole> 2) merge master -> metamodel; eventually rebase master ->
metamodel + merge -> master
[08:41] <sebersole> 3) rebase master -> metamodel; eventually rebase master ->
metamodel + merge -> master
[08:41] <hardy_> thinking ...
[08:41] <sebersole> i think its really a matter of (1) how we few the metamodel
dev and (2) whether we intended to leverage development being sucked into
metamodel from master
[08:43] <hardy_> not sure about your (1), but my main point is (2)
[08:44] <hardy_> I want to make sure that metamodel does not diverge too much
from master
[08:44] <sebersole> sure
[08:44] <sebersole> but
[08:44] <sebersole> thats not really what i mean with (2)
[08:44] <hardy_> ohh
[08:44] <sebersole> sorry, should have done those as (a) and (b) :)
[08:44] <sebersole> i think its really a matter of (a) how we few the metamodel
dev and (b) whether we intended to leverage development being sucked into
metamodel from master
[08:44] <sebersole> so for example..
[08:45] <sebersole> say we further develop multi-tenance on master
[08:45] <sebersole> then after some integration of master -> metamodel, we
leverage that new developement in some way
[08:45] <sebersole> then logically the 2 should be handled by merge
[08:46] <sebersole> because the really do have a "mixed develpment line"
[08:47] <sebersole> but if instead (and this is what i think) the integration
is more to make sure that we are not breaking tests added to master during
metamodel tests, then that is logically a rebase imho
[08:47] <sebersole> s/metamodel tests/metamodel dev
[08:47] <sebersole> then the question becomes how to best achieve rebase if
thats the route
[08:48] <hardy_> so a regular rebase of the metamodel branch on top of master
[08:48] <hardy_> that is what I meant in my email
[08:48] <sebersole> well i think we use different language for rebasing :)
[08:48] <hardy_> I would like to rebase the metamodel branch regularly onto
master
[08:48] <hardy_> maybe
[08:48] <sebersole> but i think we are saying the same thing
[08:49] <sebersole> i think of `git checkout metamodel; git rebase master` as
rebasing master on to metamodel
[08:49] <hardy_> that's what I mean as well :-)
[08:49] <sebersole> or rebasing metamodel on top of master
[08:50] <sebersole> ok
[08:50] <sebersole> we all just seem to use diff lang
[08:50] <hardy_> that's the way I say it
[08:50] <sebersole> ok
[08:51] <hardy_> my initially thought was that since we have not done this
before we should do a merge first (and then regularly rebase)
[08:51] <sebersole> so i will try rebase first
[08:51] <sebersole> not sure there is an initial diff
[08:51] <hardy_> exactly
[08:52] <sebersole> well i mean in terms of "complexity"
[08:52] <hardy_> I started to wonder as well
[08:52] <sebersole> there is obviously a diff in how the timeline ends up
[08:52] <hardy_> sure
[08:52] <sebersole> but
[08:52] <sebersole> if we do:
[08:52] <hardy_> but you will have to resolve the same amount of conflicts
[08:52] <sebersole> [08:40] <sebersole> 2) merge master -> metamodel;
eventually rebase master -> metamodel + merge -> master
[08:53] <sebersole> then the "regular" integration being merge or rebase is
irrelevant i think
[08:53] <sebersole> again, my concern is the timeline
[08:54] <sebersole> if this were local on my machine, i would unequivocally
(another new word? ;) be doing rebasing
[08:54] <sebersole> is metamodel being shared really that big of a shift that
we now merge?
[08:54] <hardy_> jump another word :-)
[08:55] <sebersole> sorry
[08:55] <sebersole> without a doubt
[08:55] <sebersole> not even a question
[08:55] <hardy_> no problem. I have my favorite dictionary handy -
http://dict.leo.org :-)
[08:55] <hardy_> and I kind of guessed anyways
[08:55] <sebersole> sweet
[08:57] <sebersole> hardy_: my (2) option is based on my experiences with
integrating pull requests that include merge commits
[08:58] <sebersole> rebase basically strips them out and reorders those commits
"to the end"
[08:58] <hardy_> right
[08:58] <hardy_> rebasing is in this sense much nicer
[08:58] <sebersole> using merge for the regular integrations has another nice
benefit
[08:59] <hardy_> however, if you rebase people will need to always get the
rebased branch
[08:59] <sebersole> namely, using rebase for the regual integration causes
"problems" in terms of ongoing metamodel dev
[08:59] <-- smarlow has left this server (Quit: Leaving).
[08:59] <sebersole> right
[08:59] <hardy_> I have no problem with that
[09:00] <hardy_> as long as the one doing the rebase gives a heads up
[09:00] <hardy_> then I can decide to either push my outstanding changes or
stash them until I get the rebased branch
[09:00] <sebersole> so you like (2) or (3)?
[09:01] <sebersole> just trying to make sure i understoidd
[09:01] --> gbadner has joined this channel
(~gbad...@c-50-132-6-30.hsd1.wa.comcast.net).
[09:02] <sebersole> meeting bot not here anyway
[09:02] <hardy_> 3
[09:02] <sebersole> ok, thanks
[09:02] <sebersole> gbadner: we just discussing optioins for integrating master
into metamodel
[09:03] <sebersole> [08:40] <sebersole> 1) merge master -> metamodel;
eventually merge metamodel -> master
[09:03] <sebersole> [08:40] <sebersole> 2) merge master -> metamodel;
eventually rebase master -> metamodel + merge -> master
[09:03] <sebersole> [08:41] <sebersole> 3) rebase master -> metamodel;
eventually rebase master -> metamodel + merge -> master
[09:03] <gbadner> thinking (slowly)
[09:03] <sebersole> np
[09:03] <sannegrinovero> sebersole, trying to summarize the long chat, you are
proposin to do frequent merges from master into metamodel, and a single final
rebase before merging metamodel in master?
[09:04] <sebersole> sannegrinovero: well merge/rebase for the regular
integrations is i think the thing to decide
[09:04] <sebersole> but
[09:04] <sannegrinovero> are that 3 different alternatives ?
[09:04] --> jpav has joined this channel (jpav@redhat/jboss/jpav).
[09:04] <sebersole> i think rebase for the final integration is def the way to
go
[09:05] <sannegrinovero> +1, and if you merge frequently from master, you would
minimize conflicts
[09:05] <gbadner> sebersole, have you tried rebasing master into metamodel?
[09:05] <sebersole> sannegrinovero: you mean conflicts at the end?
[09:05] <sebersole> gbadner: rebasing versus megring right now is going to be
the same in terms of complexity
[09:06] <sannegrinovero> sebersole, yes.
[09:06] <sebersole> sannegrinovero: well the same is true whether we rebase or
merge regularly
[09:07] <sebersole> i think really we have to look at these things:
[09:07] <sannegrinovero> right. I was thinking about it as a "merge frequently
from master" vs. "doing nothing - just merge from metadata in the end"
[09:07] <sebersole> [08:44] <sebersole> i think its really a matter of (a) how
we view the metamodel dev and (b) whether we intended to leverage development
being sucked into metamodel from master
[09:07] <sebersole> sannegrinovero: sure, thats why i started using the term
"integrate" :)
[09:08] <sebersole> its merge/rebase agnostic
[09:08] <sebersole> [08:45] <sebersole> say we further develop multi-tenance on
master
[09:08] <sebersole> [08:45] <sebersole> then after some integration of master
-> metamodel, we leverage that new developement in some way
[09:08] <sebersole> [08:45] <sebersole> then logically the 2 should be handled
by merge
[09:09] <sebersole> [08:46] <sebersole> because then we really do have a "mixed
develpment line"
[09:09] <sebersole> [08:47] <sebersole> but if instead (and this is what i
think) the integration is more to make sure that we are not breaking tests
added to master during metamodel dev, then that is logically a rebase imho
[09:10] <sebersole> [08:54] <sebersole> if this were local on my machine, i
would unequivocally be doing rebasing
[09:10] <sebersole> [08:54] <sebersole> is metamodel being shared really that
big of a shift that we now merge?
[09:10] <sebersole> so there is a shift there
[09:11] <sebersole> and the fact that rebasing + push is rewriting the shared
history
[09:11] <sebersole> but we all just need to be aware of that
[09:11] <sebersole> and whoever does the rebase+push needs to communicate when
that happens
[09:12] <sebersole> so my prefer is definitely (2) or (3)
[09:12] <sebersole> i think ultimately this should be a rebase
[09:12] <gbadner> +1
[09:13] <sebersole> i *think* using rebase for the regular integrations makes
that easier, but i am not for sure
[09:13] <sebersole> i have had pretty good results of rebasing "over" merges
[09:14] <sebersole> like that email i sent to dev awhile back about rebasing
pull requests that contain merge comits
[09:14] <gbadner> there shouldn't be much overlap in development between the 2
branch, should there?
[09:15] <sebersole> gbadner: no, i think this is mostly an exercise to pull
over any new tests
[09:15] <gbadner> oh, ok
[09:15] <sebersole> and make sure we are not breaking those as we develop
metamodel
[09:15] <sebersole> thats from my pov
[09:15] <gbadner> yeah, seems rebasing makes sense
[09:15] <hardy_> then I definitely would try with an initial rebase as well
[09:15] <sebersole> maybe others see it diff
[09:16] <sebersole> ok, then that is what i will try today
[09:17] <-- zroubali has left this server (Quit: Konversation terminated!).
[09:18] <hardy_> sebersole: good luck
[09:18] <sebersole> hehe
[09:18] <hardy_> maybe the git force be with you
[09:18] <sebersole> lol
[09:18] <hardy_> s/maybe/may/
[09:18] <sebersole> funny considering gitbu uses that star wars scene for 404
[09:19] <sebersole> this is not the page you are looking for
[09:19] <sebersole> lol
[09:21] [Whois] sjacobs is sjacobs@redhat/jboss/sjacobs (Steve Jacobs)
[09:21] [Whois] sjacobs is a user on channels: #hibernate-dev
[09:21] [Whois] sjacobs is online via niven.freenode.net (Corvallis, OR, USA).
[09:21] [Whois] sjacobs has been idle for 1 hour, 38 minutes, and 28 seconds.
[09:21] [Whois] sjacobs has been online since 06/07/12 07:42:45 AM.
[09:21] [Whois] sjacobs is logged in as sjacobs.
[09:21] [Whois] End of WHOIS list.
[09:21] <sebersole> anything else anyone wants to discuss?
[09:21] <sannegrinovero> I'd avoid the intermediate rebases.
[09:22] <sannegrinovero> (sorry was AFK)
[09:22] <sebersole> sannegrinovero: why?
[09:22] <sebersole> yes it takes more coordination
[09:22] <sannegrinovero> well we shouldn't be afraid of using merges, they have
been invented for this purpose
[09:23] <sannegrinovero> we kinda dislike merge commits, because up to this
point they where a sign of smelly process
[09:23] <sebersole> and they are here too
[09:23] <sannegrinovero> but really "smelly" just meant "different" than what
we agreed to do
[09:23] <sebersole> these 2 branches are totally isolated dev
[09:23] <sannegrinovero> but they seem to be *the* appropriate thing for this
use case
[09:23] <sannegrinovero> so we should not consider them a bad thing
[09:23] <sebersole> i disagree
[09:24] <sannegrinovero> why?
[09:24] <sebersole> metamodel is being developed in isolation
[09:24] <sannegrinovero> since you don't rewrite history, and merge tracks
exactly what happened in the same sequence people experienced the merge, it
makes it more natural to understand what is happening as it closely matches the
development timeline.
[09:24] <sebersole> if there was synergy betwen the 2 branches, then ok i can
see that the timelines are indeed mixed
[09:25] <sebersole> but that is simply not the case here
[09:25] <sebersole> sannegrinovero: thats one way to look at it sure
[09:25] <sebersole> but thats not the way i look at it
[09:25] <sebersole> nor does it seem hardy or gail look at it that way
[09:25] <sannegrinovero> did you consider that these merge commits that I'm
proposing will disappear when you rebase in the end?
[09:26] <sebersole> yep
[09:26] <sebersole> if you scroll up i discussed that :)
[09:26] <sannegrinovero> ok then, I just assume that they are basically the
"milestones" marked in the history - temporarily - which nicely replace the
emails storm you otherwise have to generate. looks like a better tool than
emails.
[09:26] <sebersole> sannegrinovero: here is the ultimate question for me...
[09:27] <sebersole> [09:10] <sebersole> [08:54] <sebersole> if this were local
on my machine, i would unequivocally be doing rebasing
[09:27] <sannegrinovero> +1, agreed that's the ultimate question.
[09:27] <sannegrinovero> I'd suggest merges because I've seen people struggling
with these rebases happening during MongoDB/OGM
[09:27] <sebersole> so does metamodel being pushed and shared change that?
[09:28] <sebersole> how so?
[09:28] <sannegrinovero> mostly because they weren't very confident with git.
that's not the case here
[09:28] <sebersole> without question there is more "danger" in using rebase for
the regular integrations
[09:28] <sebersole> exactly
[09:29] <sebersole> merging is undeniably "easier"
[09:29] <sebersole> and then rebasing at the end still gets use the singular
timeline
[09:29] <sebersole> like i said, i def prefer (2) or (3)
[09:29] <sebersole> (2) is what you seem to prefer as well
[09:29] <sannegrinovero> ok, looks good.
[09:30] <gbadner> I'm ok w/ 2)
[09:30] <sebersole> gbadner: it would be easier to deal with for you and john
and whoever else does work on metamodel
[09:31] <sebersole> ok
[09:31] <sebersole> hardy_: ?
[09:31] <sebersole> you seemed to be cool with that from when we were talking
before
[09:31] <sannegrinovero> I mean, I'm not against 3 either. your call, just
sharing our experience. I don't think you'll get in trouble with either
approach, as long as you'll all prepared for more communication and some
occasional hard core git.
[09:31] <sebersole> just trying to make sure we have a consensus
[09:31] <jpav> I missed the initiall numbered list apparently, but I'm totally
good with the rebase for the integration.
[09:32] <sebersole> [09:03] <sebersole> [08:40] <sebersole> 1) merge master ->
metamodel; eventually merge metamodel -> master\
[09:32] <sebersole> [09:03] <sebersole> [08:40] <sebersole> 2) merge master ->
metamodel; eventually rebase master -> metamodel + merge -> master
[09:32] <sebersole> [09:03] <sebersole> [08:41] <sebersole> 3) rebase master ->
metamodel; eventually rebase master -> metamodel + merge -> master
[09:33] <gbadner> sebersole, are you thinking that after the initial rebase (or
merge) that we would rebase master before pushing new commits?
[09:33] <sebersole> and the end of the day (integrating metamodel back into
master) (2) and (3) are the same outcome
[09:33] <sebersole> gbadner: no
[09:34] <sebersole> just keep rebasing metamodel
[09:34] <sebersole> i think the master->metamodel integration should be a
separate step
[09:35] <gbadner> rebase metamodel?
[09:35] <sebersole> we can decide on either a regular schedule for it or
as-needed
[09:35] <sebersole> gbadner: well assuming you use a local topic branch, yeah
[09:35] <sebersole> generally you do work with `git checkout -b HHH-123
metamodel`
[09:35] <jbossbot> jira [HHH-123] Filters for subclasses [Closed (Fixed)
Improvement, Major, Steve Ebersole] https://hibernate.onjira.com/browse/HHH-123
[09:35] <sebersole> lol
[09:36] <gbadner> yes
[09:36] <sebersole> then when you are done with that topic branch you need to
`git rebase metamodel`
[09:36] <gbadner> yeah, the usual
[09:36] <sebersole> right, so
[09:36] <sebersole> [09:34] <sebersole> just keep rebasing metamodel
[09:36] <gbadner> I was just wondering if it's worthwhile to also rebase master
[09:37] <sebersole> i'd say def not\
[09:37] <sebersole> hey guys/gals i need to run
[09:37] <sebersole> i'll work on a merge then today and push that to metamodel
[09:38] <gbadner> ok, so I assume we should hold off on new commits on metamodel
[09:38] <sebersole> nah, continue as normal
[09:38] <sebersole> i'll handle it
[09:39] <gbadner> ok
[09:39] <sebersole> dont push "just cuz" ;)
[09:39] <gbadner> heh, ok
[09:39] <sebersole> but if you push, i'll deal
[09:39] <gbadner> okiedoke
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
