[08:07] so 4.0.1 tomorrow [08:07] if you have issues scheduled that you will not get to, please unschedule them [08:08] (not push them off, unsxchedule please) [08:08] can we assign to 4.0.x to keep track of them? [08:08] no [08:09] ok [08:09] we really need to start limiting issues assigned to ourselves too [08:09] ok [08:09] thats i think why we end up with issues scheduled so much [08:09] i have that problem [08:10] i have tons of issues assigned to me atm [08:10] will you have a chance to look at the pull request for HHH-5472? [08:10] jira [HHH-5472] Delay saving an entity if it does not cascade the save to non-nullable transient entities [Open (Unresolved) Improvement, Major, Gail Badner] https://hibernate.onjira.com/browse/HHH-5472 [08:10] --> smarlow has joined this channel (~smarlow@redhat/jboss/smarlow). [08:10] gbadner: if you are interested in an issue, just comment on it. you get added to the notification list [08:11] you can also use tags/labels [08:11] yeah, or I can watch it also [08:11] gbadner: going to try tonight [08:12] we also need to decide about possibly doing one more 3.6 releasae [08:12] yeah, I think it would be a good idea [08:12] why? [08:13] gbadner: why do you think its a good idea? [08:14] just to get some bugfixes backported [08:15] I could be talked out of it though [08:15] the reason i ask is because this gets to a larger discussion [08:15] about branching? [08:15] cant that same argument be applied to another 3.3 release gbadner? [08:16] no about release management [08:16] no, not 3.3 [08:16] so then there is more to it in your mind than "just to get some bugfixes backported" [08:17] like what? [08:18] for me, the other criteria is because of the major changes in 4.0 [08:18] but see that is a pro/con as far as an argument [08:18] maybe just until more people start moving to 4.0.x and regressions are found [08:18] essentially a new 3.6 release caters to the people not wanting to upgrade to 4.0 [08:18] and fix [08:19] yeah but we *want* people moving to 4.0 [08:19] yes, I agree that it keeps people on 3.6 [08:20] anyway, i think we should do it. one last 3.6 release [08:20] i think we should do it though with 4.0.2 [08:21] that will give us 4 weeks to identify all fixes we want to port [08:21] oh, ok; yeah, that's fine [08:21] and close out 3.6 [08:22] we're back to a 4-week timebox for 4.0.x, right? [08:22] or do we just move on to 4.1? [08:22] gbadner: i think that feels right [08:23] going back to 4 weeks after the first bugfix release [08:23] +1 [08:23] we still fine tuning that specific part :) [08:23] the question is whether we can have 4.1 ready in 4 weeks [08:24] we dont have to decide that today [08:25] so i ust added 3.6.10 [08:25] and scheduled for 2/8 [08:25] when do you plan on branching 4.0? [08:26] tomorrow [08:26] after i do the release [08:26] post release will be: [08:26] oh, ok; sounds good [08:26] 1) rename the repo hibernate-core -> hibernate-orm [08:26] 2) branch 4.0 [08:28] probably good idea to create a wiki page on how to handle the rename if you have your own fork and send out the info on the dev list [08:28] hardy_: how do you "handle the rename if you have your own fork"? ;) [08:29] afair its just dropping your remote and adding a new [08:29] we don't change artifact id, right? [08:29] stliu: no [08:29] well, there are two things [08:30] your local clone and your actual github fork [08:30] locally you probably get away with changing the remote [08:30] not sure about the github fork [08:30] i'll ask on #github [08:30] you might have to throw it away and fork the new repo [08:31] and then just repush your work branches? [08:31] locally you can then of course also update the remote for your fork [08:31] (to your fork i mean) [08:31] yes [08:31] ok [08:31] problematic would be if you pushed work to your fork, but deleted it locally [08:31] like sandbox experiments [08:31] just pull it prior i think [08:31] in this case you have to make sure to pull them again first [08:32] :-) [08:32] :D [08:32] like i said i will ask on #github just to make sure [08:32] so what I am saying is that we should write a step to step list of what to do and what to thing about. basically what we just said :-) [08:32] sweet [08:32] hardy_: did you see my emails in regards to HHH-5024? [08:33] jira [HHH-5024] MetadataContext#registerAttribute does not recognize inherited fields [Open (Unresolved) Bug, Major, Steve Ebersole] https://hibernate.onjira.com/browse/HHH-5024 [08:33] could really use some advice there [08:33] i would like to get that into 4.0.1 [08:33] but if we cant, we cant [08:33] in the one case there does seem to be an issue with the generator too [08:33] I've seen the emails but failed so far to have a closer look [08:34] i am planning to work on on the generator this or maybe next week [08:34] there are several little issues which were piling up [08:34] hardy_: well i pointed out a test case that illustrates the issue [08:34] in the email i mean [08:35] hibernate-entitymanager/src/test/java/org/hibernate/ejb/test/metadata/mappedsuperclass/idclass/MappedSuperclassWithEntityWithIdClassTest.java [08:36] the static metamodel that gets generated for those classes [08:37] ok [08:37] those annotations are so confusing imo [08:38] so then i will probably push this off until after 4.0.1 [08:39] probably best [08:39] anything else we should cover? [08:39] wrt HHH-6815 (and HHH-6779 that stliu dealt with), I know I've been sitting on this for quite a while, but I think the customer that complained about the fix is right. I want to reopen the issue and check in an "unfix" to this, and just make a simple modification to the test to fix the ByteTest failure. [08:39] meeting time [08:40] <-- jbossbot has left this server (Ping timeout: 240 seconds). [08:40] basically boils down to whose perspective is more important wrt data semantics, the DB or application [08:40] jpav: iirc the issues you are talking about... [08:40] the problem is compatibility [08:41] The customer (and previous releases) assume the application can "override" the semantics, and for instance allow the app to store a -10 in the DB even though the column only supports values from 0-255 [08:41] yes, between the app and DB [08:41] no [08:41] I found a way to make an easy change to the test to get it to work with the old way the code worked [08:41] no to what? [08:41] between the app running on one version of hibernate and the app running on another [08:42] no, that's not what I meant [08:42] --> jbossbot has joined this channel (~jbossbot@redhat/jbossbot). [08:42] pk [08:42] well first, lets tralk about jira... [08:42] we do not reopen closed issues [08:42] this was something you in particular were adamant about ;) [08:43] Well, it's not closed yet I don't think, just resolved [08:43] it messes up release notes associated with past releases [08:43] is it part of a release? [08:43] thats really the more important criteria [08:43] But , yeah, I get what you mean since its been in a previous release [08:44] so you just open a new issue that "follows up on" the old [08:44] sure [08:44] (thats the link text) [08:44] k [08:44] so back to those issues [08:44] if the new behavior is "more correct" then you make this switchable [08:45] but always default to the old behavior [08:45] although, this happened as part of a major release, so... [08:46] sebersole: MappedSuperclassWithEntityWithIdClassTest.java - did you only mention this in an email or does this class exist somewhere in the source code? I cannot find it [08:46] i am also ok with making the new behavior the default (since it is now) and providing an easy switch to the legacy behavior [08:46] hardy_: ^^ i just gave you the full path [08:46] [08:35] hibernate-entitymanager/src/test/java/org/hibernate/ejb/test/metadata/mappedsuperclass/idclass/MappedSuperclassWithEntityWithIdClassTest.java [08:46] okay, I was thinking the same thing. Switchable via some new property you mean? [08:46] did you check it in recently? [08:46] hardy_: yes [08:46] ahhh [08:47] jpav: that or an easy swap to the type registry [08:47] k, I'll have to play with the latter to see the affects [08:48] anyone else seeing infinispan test failures after pulling? [08:48] sebersole: got it, thanks [08:48] gbadner: have not tried yet [08:48] but galder did just upgrade infinispan [08:48] just building the latest atm [08:48] can tell you in a few minutes [08:48] we might really need to move infinispan off somewhere else [08:48] yes, it also fails hudson master job [08:48] that is getting ridiculous [08:50] that's all I got [08:50] sebersole, you mentioned we needed to change the meeting time [08:50] i added a comment to the issue [08:52] gbadner: its ok, i'll try some other things to work around it [08:53] I need to shift back to more day hours, so changing is ok with me; keeping it the same is ok as well [08:56] ok, so to wrap up: [08:57] 1) 4.0.1 tomorrow (4/11) [08:57] 2) after 4.0.1: (a) rename repo; (b) branch 4.0 [08:58] 3) 3.6.10 in 4 weeks (2/8) along with 4.0.2 or 4.1.0 [08:58] 4) intructions on handling repo rename to follow [08:58] __EOL__