[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 (~gbadner@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